[PHP-DEV] PHP 4.0 Bug #9328 Updated: ext/pgsql/php_pgsql.h needs to include postgres_fe.h not postgres.h
ID: 9328 Updated by: sas Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: PostgreSQL related Assigned To: Comments: Fixed in CVS. Thanks for your report. Previous Comments: --- [2001-02-18 17:59:52] [EMAIL PROTECTED] Actually, you don't need EITHER file. Here is a new patch against 4.0.4pl1: $ cvs diff -c -rREL_4_0_4pl1 cvs diff: Diffing . Index: php_pgsql.h === RCS file: /cvsroot/php/ext/pgsql/php_pgsql.h,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 php_pgsql.h *** php_pgsql.h 2000/12/23 23:05:41 1.1.1.2 --- php_pgsql.h 2001/02/18 22:57:20 *** *** 29,35 #ifdef PHP_PGSQL_PRIVATE #undef SOCKET_SIZE_TYPE - #include postgres.h #include libpq-fe.h #ifdef PHP_WIN32 --- 29,34 $ --- [2001-02-18 17:37:21] [EMAIL PROTECTED] Starting with PostgreSQL 7.1beta5 (or current CVS), PHP's pgsql extension needs to only include postgres_fe.h to compile. Here is a patch: Index: php_pgsql.h === RCS file: /cvsroot/php/ext/pgsql/php_pgsql.h,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 php_pgsql.h *** php_pgsql.h 2000/12/23 23:05:41 1.1.1.2 --- php_pgsql.h 2001/02/18 21:15:45 *** *** 29,35 #ifdef PHP_PGSQL_PRIVATE #undef SOCKET_SIZE_TYPE ! #include postgres.h #include libpq-fe.h #ifdef PHP_WIN32 --- 29,35 #ifdef PHP_PGSQL_PRIVATE #undef SOCKET_SIZE_TYPE ! #include postgres_fe.h #include libpq-fe.h #ifdef PHP_WIN32 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 $ --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9328edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9004 Updated: Can not serialize($HTTP_SESSION_VARS);
ID: 9004
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: *Session related
Description: Can not serialize($HTTP_SESSION_VARS);
The "need" is to get all session variables in one string. Used for bug reporting
Previous Comments:
---
[2001-02-17 13:17:19] [EMAIL PROTECTED]
$HTTP_SESSION_VARS provides a means to access the contents of registered session
variables if you have disabled register_globals.
There is no sense in doing the following
?php
session_start();
session_register("HTTP_SESSION_VARS");
?
Neither the code shown above, nor
$s = serialize($HTTP_SESSION_VARS);
causes a crash on my system.
---
[2001-01-30 10:52:36] [EMAIL PROTECTED]
The server crashes when executing this code ??? May be this is brohibited?
---
Full Bug description available at: http://bugs.php.net/?id=9004
--
PHP Development Mailing List http://www.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] Time for 4.0.5?
what do people think about a PHP 4.0.5 release? We have about 70 change entries in NEWS. Some of the changes are fundamentally needed for some extensions to work correctly or to compile at all. mh.. what about php-gtk? is it going to be included in release? im not sure if this is ok? Peter Petermann -- PHP Development Mailing List http://www.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] Time for 4.0.5?
On Mon, Feb 19, 2001 at 09:31:01AM +0100, Sascha Schumann wrote: Hi, what do people think about a PHP 4.0.5 release? We have about 70 change entries in NEWS. Some of the changes are fundamentally needed for some extensions to work correctly or to compile at all. Let me know your thoughts. anytime - -- PHP Development Mailing List http://www.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] Time for 4.0.5?
Cameron wrote: i'll agree its about due for release, can we do SOMETHING about the download size tho? i dont really have any ideas on decent ways to shrink it but it seems to be bloating to me. could do with the mcrypt fix's and zeev's output buffer fix 1st tho . . . Hum, having just contributed to said download size... we've done our best to minimize the KLOC, removing some cruft and moving a couple of functions into a (separate) library, but we'd be down to stripping comments to go further... the only other thing I could suggest is using bzip2 instead of gzip: -rw-r--r--1 emileemile 1952068 Feb 19 10:53 php-4.0.4pl1.tar.bz -rw-r--r--1 emileemile 2439189 Feb 19 10:52 php-4.0.4pl1.tar.gz which is a 20% size reduction without changing anything else. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #6146 Updated: xml_parse() passes character entities incorrectly
ID: 6146
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: XML related
Assigned To:
Comments:
Try the code. It shows what happens. The output should be same for
both test cases (the one with entitities breaks, ie. every entity is considered
a string itself)
I'm not sure if this is a bug in PHP but more likely in expat library itself.
--Jani
Previous Comments:
---
[2001-02-15 08:51:17] [EMAIL PROTECTED]
what is wrong with the output?
---
[2000-08-14 07:45:20] [EMAIL PROTECTED]
Here are an example xml-file and php-script which demonstrates
this behaviour:
-
?xml version="1.0" ?
document
test1åäöÅÄÖ/test1
test2#229;#228;#246;#197;#196;#214;/test2
/document
-
?php
$file = "test.xml";
function characterData($parser, $data) {
print "*$data*br";
}
$xml_parser = xml_parser_create();
xml_set_character_data_handler($xml_parser, "characterData");
if (!($fp = fopen($file, "r"))) {
die("could not open XML input");
}
while ($data = fread($fp, 4096)) {
if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}
?
-
php configure line:
./configure
--prefix=/data --with-config-file-path=/data/conf
--with-mysql=/data/kolumbustori
--without-gd --disable-pear
--disable-debug
And the output with those files:
* *
* *
*åäöÅÄÖ*
* *
* *
*å*
*ä*
*ö*
*Å*
*Ä*
*Ö*
* *
--Jani
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6146edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #6146 Updated: xml_parse() passes character entities incorrectly
ID: 6146
Updated by: thies
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: XML related
Assigned To:
Comments:
that's the way expat works - you are never guaranteed that
cdata is deliverd to the callback in one piece.
Previous Comments:
---
[2001-02-19 06:03:27] [EMAIL PROTECTED]
Try the code. It shows what happens. The output should be same for
both test cases (the one with entitities breaks, ie. every entity is considered
a string itself)
I'm not sure if this is a bug in PHP but more likely in expat library itself.
--Jani
---
[2001-02-15 08:51:17] [EMAIL PROTECTED]
what is wrong with the output?
---
[2000-08-14 07:45:20] [EMAIL PROTECTED]
Here are an example xml-file and php-script which demonstrates
this behaviour:
-
?xml version="1.0" ?
document
test1åäöÅÄÖ/test1
test2#229;#228;#246;#197;#196;#214;/test2
/document
-
?php
$file = "test.xml";
function characterData($parser, $data) {
print "*$data*br";
}
$xml_parser = xml_parser_create();
xml_set_character_data_handler($xml_parser, "characterData");
if (!($fp = fopen($file, "r"))) {
die("could not open XML input");
}
while ($data = fread($fp, 4096)) {
if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}
?
-
php configure line:
./configure
--prefix=/data --with-config-file-path=/data/conf
--with-mysql=/data/kolumbustori
--without-gd --disable-pear
--disable-debug
And the output with those files:
* *
* *
*åäöÅÄÖ*
* *
* *
*å*
*ä*
*ö*
*Å*
*Ä*
*Ö*
* *
--Jani
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6146edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
I would welcome the win32 distributions packed with bzip2 as well. This algorithm is superior to anything else I know (well, at least in compression ratio), and is available to win32 users as well. Not only as a commandline tool, but as a plugin for the very popular wincmd32 too. Anything bzipped is about half the size of that thing zipped. At 13:49 19.2. 2001, Emiliano wrote the following: -- Cameron wrote: since sending this email i have been thinking a lot about it. bzip2 is fine for many sys admins but we have the problem of the redhat users (dont take this the wrong way please) that have used no other distributions and have only ever installed an rpm before, for these users bzip2 would get confusing. im more inclined to have multiple distribution's, a standard user one which would be base+mysql+mcrypt+zlib and not much more, an oracle one etc. the only problem is working out what modules people are mostly using. *grin* Ah, that should not be too hard. In fact, RedHat does ship PHP in this way I think. any other suggestions? So, about stripping those somments ... Seriously, we could offer the .tar.bz alongside the others. Those that do have bzip2 will benefit. Emile -- PHP Development Mailing List http://www.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-- Cynic: A member of a group of ancient Greek philosophers who taught that virtue constitutes happiness and that self control is the essential part of virtue. [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
Cameron wrote: since sending this email i have been thinking a lot about it. bzip2 is fine for many sys admins but we have the problem of the redhat users (dont take this the wrong way please) that have used no other distributions and have only ever installed an rpm before, for these users bzip2 would get confusing. im more Then new RPM system uses bzip2 afaik, and it isn't that different from tar.gz of course. I really don't see the problem here. Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] time to upgrade bundled PCRE?
current version is 3.4 we use 3.2 andrei? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
any other suggestions? There has been talk on here, or maybe on the QA list about a web page where you tick the items you want, and just download the necessary components. Maybe this was just in the context of PEAR - I can't remember. Anyway, is anyone working on this? It seems to be a good solution to me (but then I don't understand how the config and .m4 stuff works!). Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- PHP Development Mailing List http://www.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] Time for 4.0.5?
On Mon, 19 Feb 2001, Cynic wrote: I would welcome the win32 distributions packed with bzip2 as well. This algorithm is superior to anything else I know (well, at least in compression ratio), and is available to win32 users as well. Not only as a commandline tool, but as a plugin for the very popular wincmd32 too. Anything bzipped is about half the size of that thing zipped. It's only that the most users se WinZip, which does not support it. Derick Rethans - PHP: Scripting the Web - www.php.net - [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] Time for 4.0.5?
Phil Driscoll wrote: any other suggestions? There has been talk on here, or maybe on the QA list about a web page where you tick the items you want, and just download the necessary components. Maybe this was just in the context of PEAR - I can't remember. Anyway, is anyone working on this? It seems to be a good solution to me (but then I don't understand how the config and .m4 stuff works!). that is pretty simple, make the client who is compiling the source do a ./buildconf first. if noone is working on this i am willing to offer to help but for something like this i would prefer 2 or 3 coders doing it . . . -- PHP Development Mailing List http://www.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] time to upgrade our bundled expat?
On Mon, Feb 19, 2001 at 02:05:28PM +0100, Emiliano wrote: "Thies C. Arntzen" wrote: v 1.95.1 is out (http://expat.sourceforge.net) has anybody played with it? We use it a lot. Works well, supports multiple charsets, and is now in as sane library format so internalizatin isn't strictly necesary anymore (although there can be reasons to do so all the same, of course). Is there anything specific you want to know about it? -was the upgrade from the original jclark-dist painfull at all? -are there any known incompatiblities? -do you think that if we upgrade the PHP 4 bundled expat we'll hit any wall? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
Cameron wrote: Phil Driscoll wrote: There has been talk on here, or maybe on the QA list about a web page where you tick the items you want, and just download the necessary components. that is pretty simple, make the client who is compiling the source do a ./buildconf first. if noone is working on this i am willing to offer to help but for something like this i would prefer 2 or 3 coders doing it . . . we had a related idea to not include extensions considered experimental like ext/zziplib that marked by an EXPERIMENTAL file in their ext dir -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4 -- PHP Development Mailing List http://www.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] Time for 4.0.5?
On Mon, 19 Feb 2001, Hartmut Holzgraefe wrote: we had a related idea to not include extensions considered experimental like ext/zziplib that marked by an EXPERIMENTAL file in their ext dir I'm not a supporter of this, the Sablotron is marked EXPERIMENTAL, but it should definitely be in the distro. Maybe we should decide on PHP-DEV / PHP-QA what will be included in the distro? Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands - -- PHP Development Mailing List http://www.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] Time for 4.0.5?
On Mon, 19 Feb 2001, Derick Rethans wrote: On Mon, 19 Feb 2001, Sascha Schumann wrote: what do people think about a PHP 4.0.5 release? Let me know your thoughts. Sounds like a good idea, but I would like to fix the bugs in the mcrypt extension before this release. What about making March 1, 2001 making the day for RC 1? I need some time too (one or two weeks) to finish mnoGoSearch extension to support all of features of mnoGoSearch - 3.1.10. It seems to me that March 1 is the resonable date for RC1 8) -- Regards. Sergey aka gluke. -- PHP Development Mailing List http://www.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] time to upgrade our bundled expat?
"Thies C. Arntzen" wrote: We use it a lot. Works well, supports multiple charsets, and is now in as sane library format so internalizatin isn't strictly necesary anymore (although there can be reasons to do so all the same, of course). Is there anything specific you want to know about it? -was the upgrade from the original jclark-dist painfull at all? We haven't seen any API changes ourselves, and I think we use a fairly sizeable part of the API. We had our own version of expat-lib, built from jclark-dist, and include file name changes aside, it was painless. -are there any known incompatiblities? Not that I know of, altough ISTR that apache had renamed some function names for their internalized version. Our resident expat 'expert' will be online in a few hours and I'm sure he can give you more details. -do you think that if we upgrade the PHP 4 bundled expat we'll hit any wall? In what sense? Just to satisfy my curiosity, why is expat being internalized when it's available as a library? To minimize external dependancies? Emile -- PHP Development Mailing List http://www.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] Time for 4.0.5?
At 15:05 19.2. 2001, Derick Rethans wrote the following: -- On Mon, 19 Feb 2001, Cynic wrote: I would welcome the win32 distributions packed with bzip2 as well. This algorithm is superior to anything else I know (well, at least in compression ratio), and is available to win32 users as well. Not only as a commandline tool, but as a plugin for the very popular wincmd32 too. Anything bzipped is about half the size of that thing zipped. It's only that the most users se WinZip, which does not support it. Derick Rethans "If you want to save some bandwidth, here's the distro in a bzipped archive. bzip2 plugin for Windows Commander is available for free at www.ghisler.com." I believe that a bzip verion of the large win32 distro would be somewhere about 2.3MB. That's quite nice, compared to 3.6MB of the zip file. Cynic: A member of a group of ancient Greek philosophers who taught that virtue constitutes happiness and that self control is the essential part of virtue. [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Access to CVS
Dear All! I have again requested access to CVS to work on mnogosaearch documentation. Could anyone confirm registration please? Thanx Dmitry
RE: [PHP-DEV] Time for 4.0.5?
Hum, having just contributed to said download size... we've done our best to minimize the KLOC, removing some cruft and moving a couple of functions into a (separate) library, but we'd be down to stripping comments to go further... the only other thing I could suggest is using bzip2 instead of gzip: At the moment I would personally advocate adding a EXPERIMENTAL file to midgard firstly because the midgard team themselves state that its still Beta and also if it is moved from main CVS at some point to PEAR etc then it would probably be best not to distribute it with PHP at any point. I also feel due to the amount of changes that have been made to midgard CVS in past few days/weeks it doesnt to me seem stable enough or tested enough (at least this beta version) to distribute with a release. Lets give it a bit of time in CVS before we distribute it with PHP Releases. James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0 Bug #9197: crash in _efree
could you plz try:
?
$Conn = OCINLogon ('vignette', 'vignette', 'wom_dev');
$Clob = OCINewDescriptor($Conn, OCI_D_LOB);
$ExtraXML = $Clob-load();
?
if that still causes the crash then the bug is fixed in CVS!
Not sure what that was supposed to do ;-), but it caused the same crash.
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] phpize problem
sascha, phpize configure does not work if try to external-compile any bundled modules as the generated php_config.h is never included (the one from /usr/local/include is found first) and thereby the #define COMPILE_module_DL 1 is not seen by cpp so that #ifdef COMPILE_DL_SABLOT ZEND_GET_MODULE(sablot) #endif does not define the get_module() function. suggestions? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9197: crash in _efree
On Mon, Feb 19, 2001 at 08:23:42AM -0700, David Benson wrote:
could you plz try:
?
$Conn = OCINLogon ('vignette', 'vignette', 'wom_dev');
$Clob = OCINewDescriptor($Conn, OCI_D_LOB);
$ExtraXML = $Clob-load();
?
if that still causes the crash then the bug is fixed in CVS!
Not sure what that was supposed to do ;-), but it caused the same crash.
nothing;-) - but your crash should be fixed in CVS. just examine
your code-snippet again and you'll see that the sequence that
caused your crash can be reduced to the 3 liner i sent.
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Time for 4.0.5?
Can we propose extensions outside of the main distribution ? I like the idea of downloading what you want. Through a form, you would chose the extensions you need, then submit and receive a custom GZIP or BZ2 file. It sounds doable. Any constraint, dependency to work out ? Yes, the m4 stuff... Can we open a thread on that specific topic of a PHP-downloader ? * Regarding midgard, although it is considered beta, I'm for including it into the main distrib for RC1, so that people can test it and eventually the midgard team can release a final version before 4.0.5 ships. hellekin -- PHP Development Mailing List http://www.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] time to upgrade bundled PCRE?
On Mon, 19 Feb 2001, Thies C. Arntzen wrote: current version is 3.4 we use 3.2 andrei? I will, probably in the next couple of days. -Andrei * On the keyboard of life, always keep one finger on the escape key. * -- PHP Development Mailing List http://www.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] time to upgrade our bundled expat?
On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote: "Thies C. Arntzen" wrote: We use it a lot. Works well, supports multiple charsets, and is now in as sane library format so internalizatin isn't strictly necesary anymore (although there can be reasons to do so all the same, of course). Is there anything specific you want to know about it? -was the upgrade from the original jclark-dist painfull at all? We haven't seen any API changes ourselves, and I think we use a fairly sizeable part of the API. We had our own version of expat-lib, built from jclark-dist, and include file name changes aside, it was painless. cool - i'll try to bump up the bundled expat then. -are there any known incompatiblities? Not that I know of, altough ISTR that apache had renamed some function names for their internalized version. Our resident expat 'expert' will be online in a few hours and I'm sure he can give you more details. i think we have some namespace protection for "ours" as well. -do you think that if we upgrade the PHP 4 bundled expat we'll hit any wall? In what sense? Just to satisfy my curiosity, why is expat being internalized when it's available as a library? To minimize external dependancies? yep, more and more ppl are using xml so bundleing reduces the "noise" on the ML:-) we did the same with the mysql client-lib for the very same reason. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] time to upgrade our bundled expat?
On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote: "Thies C. Arntzen" wrote: We use it a lot. Works well, supports multiple charsets, and is now in as sane library format so internalizatin isn't strictly necesary anymore (although there can be reasons to do so all the same, of course). Is there anything specific you want to know about it? -was the upgrade from the original jclark-dist painfull at all? We haven't seen any API changes ourselves, and I think we use a fairly sizeable part of the API. We had our own version of expat-lib, built from jclark-dist, and include file name changes aside, it was painless. -are there any known incompatiblities? Not that I know of, altough ISTR that apache had renamed some function names for their internalized version. Our resident expat 'expert' will be online in a few hours and I'm sure he can give you more details. maybe they could enlighten me what advantages we'll see if we upgrade? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
"Hellekin O. Wolf" wrote: Can we propose extensions outside of the main distribution ? I like the idea of downloading what you want. Through a form, you would chose the extensions you need, then submit and receive a custom GZIP or BZ2 file. It sounds doable. Any constraint, dependency to work out ? Yes, the m4 stuff... Can we open a thread on that specific topic of a PHP-downloader ? * Regarding midgard, although it is considered beta, I'm for including it into the main distrib for RC1, so that people can test it and eventually the midgard team can release a final version before 4.0.5 ships. Yes. We're gearing up for final beta (or RC, would be another term for it) end of this week. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9333 Updated: imap_fetchstructure()
ID: 9333 Updated by: chagenbu Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Assigned To: Comments: Can you please use more words to describe this problem, and perhaps provide some example code and an example message? Previous Comments: --- [2001-02-19 06:01:08] [EMAIL PROTECTED] Hi. I find bug IMAP related. That is imap_fetchstructure. In returned Objects for imap_fetchstructure() function, If type is application , return value must be 3. But return value was 0. Please Check this function in application type. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9333edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9337: make in_array return key, if searched value was found
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.4pl1 PHP Bug Type: Feature/Change Request Bug description: make in_array return key, if searched value was found in_array() currently returns only true/false on whether or not a searched-for value is in a given array. I would like it to return the key of the array's element when value was found, and false otherwise. This should not break existing code using in_array(). -- Edit Bug report at: http://bugs.php.net/?id=9337edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337: make in_array return key, if searchedvalue was found
Andrei Zmievski wrote: Really? What if the key is 0? Then we're fucked, damn it :-( -- sebastian bergmann e-mail : [EMAIL PROTECTED] homepage : http://www.sebastian-bergmann.de make a gift : http://wishlist.sebastian-bergmann.de measure the usability of your web application - 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] time to upgrade our bundled expat?
On Mon, Feb 19, 2001 at 05:29:37PM +0100, Emiliano wrote: "Thies C. Arntzen" wrote: Not that I know of, altough ISTR that apache had renamed some function names for their internalized version. Our resident expat 'expert' will be online in a few hours and I'm sure he can give you more details. maybe they could enlighten me what advantages we'll see if we upgrade? I'll leave this one to Alexander. I've already answered, unfortunately, privately to Thies :-) -- Sincerely yours, Alexander Bokovoy The Midgard Project | www.midgard-project.org |Aurora RD team Minsk Linux Users Group |www.minsk-lug.net| www.aurora-linux.com IPLabs Linux Team| linux.iplabs.ru | Architecte Open Source -- Nothing ever becomes real until it is experienced. - John Keats -- PHP Development Mailing List http://www.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] time to upgrade our bundled expat?
On Mon, Feb 19, 2001 at 02:09:36PM +0100, Thies C. Arntzen wrote: On Mon, Feb 19, 2001 at 02:05:28PM +0100, Emiliano wrote: "Thies C. Arntzen" wrote: v 1.95.1 is out (http://expat.sourceforge.net) has anybody played with it? We use it a lot. Works well, supports multiple charsets, and is now in as sane library format so internalizatin isn't strictly necesary anymore (although there can be reasons to do so all the same, of course). Is there anything specific you want to know about it? -was the upgrade from the original jclark-dist painfull at all? It was painless in sense that there was nothing to change in client code except for #include expat.h instead of those two headers. -are there any known incompatiblities? None. -do you think that if we upgrade the PHP 4 bundled expat we'll hit any wall? Be sure to make good configure detection for existing system library. You can just borrow it from Midgard library, it works fine for us for many systems with different packaged versions of Expat (OpenBSD, FreeBSD, Debian, RH, Mandrake/MandrakeCooker, Conectiva, etc). -- Sincerely yours, Alexander Bokovoy The Midgard Project | www.midgard-project.org |Aurora RD team Minsk Linux Users Group |www.minsk-lug.net| www.aurora-linux.com IPLabs Linux Team| linux.iplabs.ru | Architecte Open Source -- Nothing ever becomes real until it is experienced. - John Keats -- PHP Development Mailing List http://www.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] time to upgrade our bundled expat?
On Mon, Feb 19, 2001 at 04:35:50PM +0100, Thies C. Arntzen wrote: On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote: "Thies C. Arntzen" wrote: We use it a lot. Works well, supports multiple charsets, and is now in as sane library format so internalizatin isn't strictly necesary anymore (although there can be reasons to do so all the same, of course). Is there anything specific you want to know about it? -was the upgrade from the original jclark-dist painfull at all? We haven't seen any API changes ourselves, and I think we use a fairly sizeable part of the API. We had our own version of expat-lib, built from jclark-dist, and include file name changes aside, it was painless. -are there any known incompatiblities? Not that I know of, altough ISTR that apache had renamed some function names for their internalized version. Our resident expat 'expert' will be online in a few hours and I'm sure he can give you more details. maybe they could enlighten me what advantages we'll see if we upgrade? Well, first advantage is that Clark Cooper's team now is official Expat team, JC has delegated expat development to them, so this Expat 1.95.1 is latest official stable version. Second, several bugs were fixed, look their project site for details. Third, autoconf/automake now used to configure it which is much more painless. Fourth, name space support was extended, support for own memory management was added, set of functionality from Cooper's perl-expat was integrated. -- Sincerely yours, Alexander Bokovoy The Midgard Project | www.midgard-project.org |Aurora RD team Minsk Linux Users Group |www.minsk-lug.net| www.aurora-linux.com IPLabs Linux Team| linux.iplabs.ru | Architecte Open Source -- Nothing ever becomes real until it is experienced. - John Keats -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9161 Updated: Undefined symbols in static apache build using PHP 4.0.4pl1
ID: 9161 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Description: Undefined symbols in static apache build using PHP 4.0.4pl1 No help. I even started totally from scratch (removing all apache and php files and re-untaring them) and I get the same error. Unfortunatley when I build Apache to run PHP dynamically, when I run: ./apachectl configtest the error I get is: Syntax error on line 207 of /usr/local/apache17/conf/httpd.conf: Cannot load /usr/local/apache17/libexec/libphp4.so into server: ld.so.1: /usr/local/apache17/bin/httpd: fatal: relocation error: file /usr/local/apache17/libexec/libphp4.so: symbol pcre_free: referenced symbol not found So on Solaris 2.6 (gcc 2.95.2) I'm stuck either way (static or dynamic) since both give me undefines. Any other suggestions? Previous Comments: --- [2001-02-15 13:23:02] [EMAIL PROTECTED] No help. I even started totally from scratch (removing all apache and php files and re-untaring them) and I get the same error. Unfortunatley when I build Apache to run PHP dynamically, when I run: ./apachectl configtest the error I get is: Syntax error on line 207 of /usr/local/apache17/conf/httpd.conf: Cannot load /usr/local/apache17/libexec/libphp4.so into server: ld.so.1: /usr/local/apache17/bin/httpd: fatal: relocation error: file /usr/local/apache17/libexec/libphp4.so: symbol pcre_free: referenced symbol not found So on Solaris 2.6 (gcc 2.95.2) I'm stuck either way (static or dynamic) since both give me undefines. Any other suggestions? --- [2001-02-14 14:11:33] [EMAIL PROTECTED] Try doing 'make clean ; make install' for PHP 4 and then try making Apache again. --Jani --- [2001-02-07 13:18:52] [EMAIL PROTECTED] apache_1.3.17 php-4.0.4pl1 (Solaris 2.6 GCC 2.95.2) Atempting to static link php into apache. Getting undefined symbols in apache (shown below). config'd apache 1st, then config'd php using: ./configure --with-mysql --with-apache=../apache_1.3.17 --enable-track-vars did a make and make install and all worked. Then configured apache with: ./configure --prefix=/opt/apache --activate-module=src/modules/php4/libphp4.a and make fails with the following. Suggestions? gcc -DSOLARIS2=260 -I/opt/local/src/php-4.0.4pl1 -I/opt/local/src/php-4.0.4pl1/ main -I/opt/local/src/php-4.0.4pl1/main -I/opt/local/src/php-4.0.4pl1/Zend -I/op t/local/src/php-4.0.4pl1/Zend -I/opt/local/src/php-4.0.4pl1/TSRM -I/opt/local/sr c/php-4.0.4pl1/TSRM -I/opt/local/src/php-4.0.4pl1 -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` -o httpd buildmark.o modules.o modules/php4/libphp4.a modules/standard/lib standard.a main/libmain.a ./os/unix/libos.a ap/libap.a lib/expat-lite/libexpat. a -R/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -L/usr/uc blib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -Lmodules/php4 -L../mo dules/php4 -L../../modules/php4 -lmodphp4 -lpam -ldl -lresolv -lresolv -lm -ld l -lcrypt -lnsl -lsocket -lsocket -lgcc -lsocket -lnsl Undefined first referenced symbol in file php_register_variable modules/php4/libphp4.a(mod_php4.o) core_globalsmodules/php4/libphp4.a(mod_php4.o) sapi_startupmodules/php4/libphp4.a(mod_php4.o) sapi_shutdown modules/php4/libphp4.a(mod_php4.o) zend_ini_rshutdown modules/php4/libphp4.a(mod_php4.o) php_module_shutdown_for_execmodules/php4/libphp4.a(mod_php4.o) apache_php_module_main modules/php4/libphp4.a(mod_php4.o) php_request_shutdown_for_exec modules/php4/libphp4.a(mod_php4.o) zend_hash_apply modules/php4/libphp4.a(mod_php4.o) executor_globalsmodules/php4/libphp4.a(mod_php4.o) zend_hash_destroy modules/php4/libphp4.a(mod_php4.o) _estrdupmodules/php4/libphp4.a(mod_php4.o) zend_error modules/php4/libphp4.a(mod_php4.o) sapi_get_default_content_type modules/php4/libphp4.a(mod_php4.o) php_module_shutdown_wrapper modules/php4/libphp4.a(mod_php4.o) sapi_globalsmodules/php4/libphp4.a(mod_php4.o) zend_startup_module modules/php4/libphp4.a(mod_php4.o) php_request_shutdownmodules/php4/libphp4.a(mod_php4.o) php_handle_aborted_connection modules/php4/libphp4.a(mod_php4.o) zend_hash_add_or_update modules/php4/libphp4.a(mod_php4.o) zend_alter_ini_entrymodules/php4/libphp4.a(mod_php4.o) apache_module_entry modules/php4/libphp4.a(mod_php4.o) zend_hash_merge_ex
[PHP-DEV] license question for a module...
Hi! I've finished a first version of the dbx module (database abstraction (in C)) and I want to open-source this module (as a self-contained extension). What license should I use? I want it to be very open, but maintain a copyright notice (much like the PHP license). Or better, can I donate this to the PHP group and get it distributed as part of PHP (I've seen mentions of selective packaging/downloading, so people wouldn't be forced to download it). Cheerio, Marc. BTW could I steal and modify the PHP license if necessary??? ;-) The DBX License, version 0.01 Copyright (c) 2001 Guidance bv. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name "DBX" must not be used to endorse or promote products derived from this software without prior permission from Guidance bv. This does not apply to add-on libraries or tools that work in conjunction with DBX. In such a case the DBX name may be used to indicate that the product supports DBX. 4. Guidance bv may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by Guidance bv. No one other than Guidance bv has the right to modify the terms applicable to covered code created under this License. 5. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes DBX, freely available from http://www.guidance.nl/dbx". 6. The software is an add-on to PHP, which is freely available from http://www.php.net. Be sure to read their license as well. THIS SOFTWARE IS PROVIDED BY GUIDANCE BV ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL GUIDANCE BV OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Guidance bv can be contacted via Email at [EMAIL PROTECTED] For more information on Guidance bv and the DBX project, please see http://www.guidance.nl. The software is an add-on to the PHP project, whihc consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via Email at [EMAIL PROTECTED] For more information on the PHP Group and the PHP project, please see http://www.php.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] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
ID: 9337 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Feature/Change Request Assigned To: Comments: maybe a fourth parameter switch to avoid 0-false problems? Previous Comments: --- [2001-02-19 11:18:18] [EMAIL PROTECTED] in_array() currently returns only true/false on whether or not a searched-for value is in a given array. I would like it to return the key of the array's element when value was found, and false otherwise. This should not break existing code using in_array(). --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9337edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9338: in_array 'strict' parameter is not documented (properly)
From: [EMAIL PROTECTED] Operating system: * PHP version: 4.0 Latest CVS (19/02/2001) PHP Bug Type: Documentation problem Bug description: in_array 'strict' parameter is not documented (properly) look at http://www.php.net/in_array that documentation should not help anyone understanding what 'strict' does -- Edit Bug report at: http://bugs.php.net/?id=9338edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
How about using array_keys($array, $value) to find the key?
obviously it is cheaper to let in_array return it and it is more php 4
stylish, we have booleans, why not use them?
if ($key=in_array()) do_someting_with_key($key);
is less expensive than
if (in_array()) {
$key=array_keys($array,$value);
do_something_with_key($key); }
--
Andr Langhorstt: +49 331 5811560
[EMAIL PROTECTED] m: +49 173 9558736
* PHP Quality Assurance http://qa.php.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] PHP 4.0 Bug #9339: infinite loop in wordwrap
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.4pl1
PHP Bug Type: Strings related
Bug description: infinite loop in wordwrap
The following line seems to loop forever:
echo wordwrap("abcdefghijklmnopqr", 10, "\r\n");
--
Edit Bug report at: http://bugs.php.net/?id=9339edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
Some of my thoughts: 1. if you change the return value of in_array to return the key, you can get a false error in your if statement, imagine if in_array found the element in key 0? : ) 2. I would say that returning a key is a bit more useful then an option that does not reset the internal pointer or not, though I can see a use of it I do agree that having too many parameters is a bad thing, but if this is a concern what about making another function? There seems to be a large desire to see the key of in_array (see the haystack comment in docs) -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Andr Langhorst" [EMAIL PROTECTED] Cc: "PHP Development" [EMAIL PROTECTED] Sent: Monday, February 19, 2001 11:36 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found On Mon, 19 Feb 2001, Andr Langhorst wrote: How about using array_keys($array, $value) to find the key? obviously it is cheaper to let in_array return it and it is more php 4 stylish, we have booleans, why not use them? if ($key=in_array()) do_someting_with_key($key); So, you suggest putting in 4th parameter? Then someone on php-general suggested a few months ago to put in another parameter that controls whether in_array() moves internal pointer or not.. Too many parameters. -Andrei * Power corrupts. Atomic power corrupts atomically. * -- PHP Development Mailing List http://www.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] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
On Mon, 19 Feb 2001, Jason Greene wrote: Some of my thoughts: 1. if you change the return value of in_array to return the key, you can get a false error in your if statement, imagine if in_array found the element in key 0? : ) 2. I would say that returning a key is a bit more useful then an option that does not reset the internal pointer or not, though I can see a use of it I do agree that having too many parameters is a bad thing, but if this is a concern what about making another function? There seems to be a large desire to see the key of in_array (see the haystack comment in docs) We can change in_array() to return the the key if it's found, and false if it's not, but imagine all the scripts it would break.. -Andrei * The future is not what it used to be. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
We can change in_array() to return the the key if it's found, and false if it's not, but imagine all the scripts it would break.. about 1/4th of mine : ) Well I think the basic problem is that people are using in_array against its intention. It is a Boolean function, and that really shouldn't be changed. We could create another function that is more designed for searching? perhaps array_find? I wouldn't mind spending time on this if agreed upon. -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: "Andr Langhorst" [EMAIL PROTECTED]; "PHP Development" [EMAIL PROTECTED] Sent: Monday, February 19, 2001 11:50 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found On Mon, 19 Feb 2001, Jason Greene wrote: Some of my thoughts: 1. if you change the return value of in_array to return the key, you can get a false error in your if statement, imagine if in_array found the element in key 0? : ) 2. I would say that returning a key is a bit more useful then an option that does not reset the internal pointer or not, though I can see a use of it I do agree that having too many parameters is a bad thing, but if this is a concern what about making another function? There seems to be a large desire to see the key of in_array (see the haystack comment in docs) -Andrei * The future is not what it used to be. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
On Mon, 19 Feb 2001, Jason Greene wrote: We can change in_array() to return the the key if it's found, and false if it's not, but imagine all the scripts it would break.. about 1/4th of mine : ) Well I think the basic problem is that people are using in_array against its intention. It is a Boolean function, and that really shouldn't be changed. We could create another function that is more designed for searching? perhaps array_find? I wouldn't mind spending time on this if agreed upon. Could be done. The way I'd do it is have one php_in_array() C function that gets parameters passed through from in_array() and array_find() as well as a flag indicating whether to just return true/false or the actual key. -Andrei "The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. " -- Sir George Jessel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
I agree, That way we don't duplicate code, and we don't have different behavior.. Ill work on this sometime today -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: "Andr Langhorst" [EMAIL PROTECTED]; "PHP Development" [EMAIL PROTECTED] Sent: Monday, February 19, 2001 12:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found On Mon, 19 Feb 2001, Jason Greene wrote: We can change in_array() to return the the key if it's found, and false if it's not, but imagine all the scripts it would break.. about 1/4th of mine : ) Well I think the basic problem is that people are using in_array against its intention. It is a Boolean function, and that really shouldn't be changed. We could create another function that is more designed for searching? perhaps array_find? I wouldn't mind spending time on this if agreed upon. Could be done. The way I'd do it is have one php_in_array() C function that gets parameters passed through from in_array() and array_find() as well as a flag indicating whether to just return true/false or the actual key. -Andrei "The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. " -- Sir George Jessel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9340: usleep function doesn't work properly under winNT 4.0
From: [EMAIL PROTECTED]
Operating system: winNT 4.0
PHP version: 4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description: usleep function doesn't work properly under winNT 4.0
here is the wrong code (current) + my correction:
Wrong (current)
PHP_FUNCTION(usleep)
{
#if HAVE_USLEEP
pval **num;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, num) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_long_ex(num);
usleep((*num)-value.lval);
#endif
}
Correction
PHP_FUNCTION(usleep)
{
pval **num;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, num) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_long_ex(num);
#if HAVE_USLEEP
usleep((*num)-value.lval);
#elif PHP_WIN32
Sleep( ((*num)-value.lval+999)/1000);
#endif
}
Dror.
--
Edit Bug report at: http://bugs.php.net/?id=9340edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
Could be done. The way I'd do it is have one php_in_array() C function that gets parameters passed through from in_array() and array_find() as well as a flag indicating whether to just return true/false or the actual key. what about not touching the internal pointer? there in_array would finally get a fourth parameter, not? andr -- Andr Langhorstt: +49 331 5811560 [EMAIL PROTECTED] m: +49 173 9558736 * PHP Quality Assurance http://qa.php.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] Licensing Question
just for the record, which licenses are compatible with the PHP license ? There is an extension i'm working on that would be sufficiently useful to include in the main distribution, it currently uses code derived from an MPL'ed project. i'd rather not have to rewrite those portions of the code. i think there should be something definitive posted about license compatibilities, especially as the number of extensions increase. -- _ "Fried Ice-Cream is a reality !" - George Clinton -- PHP Development Mailing List http://www.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] Pointer to a method
I need to get a pointer to a method, something like:
class SomeClass
{
function foo()
{
echo "HiYa!";
}
}
MyClass = new SomeClass;
Now, the only way to access the function foo is $MyClass-foo(); but I want
to get a pointer to that method wich I could store in an array, something
like:
$Pointer = "MyClass-foo";
And later, execute the method by doing:
$$Pointer();
But this doesn't works ... Why? How can I do this?
___
Lloren Herrera
www.Hexoplastia.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] globals.h and notes_globals.h
Hello, This is probably a simple questions, but... In the notes api provided, there's a file called globals.h When another globals.h exists, how to I make sure it's the notes api file I want? I don't think specifying a path is the right idea? Should I rename the file to notes_globals.h in the api? But then everyone will have to do that. Suggestions appreciated. Thanks, Brad Atkins Manager, Technical Development http://www.youreshop.com 1-877-YRE-4YOU (Toll free US Canada) 1-705-692-3442 (International) -- PHP Development Mailing List http://www.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] Time for 4.0.5?
At 09:31 AM 2/19/2001 +0100, Sascha Schumann wrote: Hi, what do people think about a PHP 4.0.5 release? We have about 70 change entries in NEWS. Some of the changes are fundamentally needed for some extensions to work correctly or to compile at all. Let me know your thoughts. Our Launchpad (QA) guys have a few fixes to go into the CVS. I think it will be done by the end of the week. So I think March 1st sounds OK for branching off RC1. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9341: php -l file.php seg faults, dumps core
From: [EMAIL PROTECTED] Operating system: RH7.0 PHP version: 4.0 Latest CVS (19/02/2001) PHP Bug Type: Reproduceable crash Bug description: "php -l file.php" seg faults, dumps core Running the CGI version, if you do a "php -l file.php" (i.e. the "lint" option) on a file that has syntax errors, PHP doesn't report anything but segfaults and dumps core. Backtrace reveals: #0 destroy_op_array (op_array=0x0) at zend_opcode.c:144 #1 0x8066072 in php_lint_script (file=0xba60) at main.c:1236 #2 0x8064748 in main (argc=3, argv=0xbb04) at cgi_main.c:739 #3 0x4026ab5c in __libc_start_main (main=0x8063fc4 main, argc=3, ubp_av=0xbb04, init=0x8061b74 _init, fini=0x810cc3c _fini, rtld_fini=0x4000d634 _dl_fini, stack_end=0xbafc) at ../sysdeps/generic/libc-start.c:129 My config line: ./configure \ --with-mysql=/usr/local \ --disable-pear \ --enable-track-vars \ --disable-debug \ --disable-magic-quotes \ --enable-ftp \ --with-gettext \ --with-xml \ --with-dom \ --enable-wddx \ --with-curl \ --with-pgsql \ --with-zlib \ --enable-versioning \ --enable-sockets \ --with-openssl \ --with-snmp \ --with-mcrypt - Colin -- Edit Bug report at: http://bugs.php.net/?id=9341edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9265 Updated: passing preg_split a limit parameter of 0 supresses all matches
ID: 9265
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: PCRE related
Assigned To:
Comments:
As far as I remember, 0 has never meant "no limit" - the value for that is -1. But the
documentation does need to be updated.
Previous Comments:
---
[2001-02-14 16:33:50] [EMAIL PROTECTED]
Somewhere in the last few weeks, preg_split changed so that specifiying a limit
parameter of 0 returns the string to be split unchanged. Before that, 0 was seemingly
treated as no limit, meaning that you could safely specify 0 as the limit argument in
order to specify a flag as the fourth argument.
?php
$foo = 'a|b|c|d';
$m = preg_split('/|/', $foo, 0);
var_dump($m);
?
will return everything in the same array, whereas if the limit argument is left off
(or increased), the string gets split up. The behavior allowing 0 to be no limit
should be returned, or another safe argument for limit that means no limit documented.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9265edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9342: 508 Bad Gateway Error
From: [EMAIL PROTECTED] Operating system: Zeus PHP version: 4.0.4pl1 PHP Bug Type: Other web server Bug description: 508 Bad Gateway Error Hi, We are running PHP on a Zeus web server with a Sybase Database. We seem to be receiving a lot of 508 Bad Gateway Errors. It seems like php is dropping connections to the database when connecting with Sybase. I was wondering if their is a solution to this problem that I am overseeing. We have about 75 raw clicks a day and we receive about 7000 bad gateway errors a day. I would appreciate any information you can give me. Could the problem be a connection problem with Sybase or is it a problem with Zeus? The problem has gotten so bad that one of our programmers was forced to write a script to refresh the page when a 508 bad gateway error occured. Thanks in advance Bill Cuevas CEN 954-563-9008 ext. #243 -- Edit Bug report at: http://bugs.php.net/?id=9342edit=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] imap config.m4 confusion
Hi,
Trying to add a bit of functionality to the imap code, mainly an
imap_set_quota function for PHP to call.
This functionality is already in existence in the c-client library under
the imap4rc1.{c|h} file (function is imap_setquota). My understanding
though, is to include the c-client.h file (on FreeBSD in
/usr/local/include/c-client) which in turn includes the mail.h and the
imap4r1.h files.
So, I changed the php_imap.h file to show:
From:
#include "mail.h"
#include "rfc822.h"
#include "modules.h"
To:
#include "c-client.h"
#include "rfc822.h"
#include "modules.h"
Altered the ext/imap/config.m4 to select the proper location first with
the following change:
From:
if test "$PHP_IMAP" != "no"; then
for i in /usr/local /usr $PHP_IMAP; do
IMAP_INC_CHK()
el[]IMAP_INC_CHK(/include)
el[]IMAP_INC_CHK(/include/imap)
el[]IMAP_INC_CHK(/include/c-client)
el[]IMAP_INC_CHK(/imap)
el[]IMAP_INC_CHK(/c-client)
fi
done
To:
if test "$PHP_IMAP" != "no"; then
for i in /usr/local /usr $PHP_IMAP; do
IMAP_INC_CHK()
el[]IMAP_INC_CHK(/include/c-client)
el[]IMAP_INC_CHK(/include)
el[]IMAP_INC_CHK(/include/imap)
el[]IMAP_INC_CHK(/imap)
el[]IMAP_INC_CHK(/c-client)
fi
done
rebuilt my configure script, and went to recompile. Ran into this
error..
gcc -I. -I/home/kalowsky/php/php4/main -I/home/kalowsky/php/php4/main
-I/home/kalowsky/php/php4 -I/usr/local/include/apache
-I/home/kalowsky/php/php4/Zend -I/usr/local/include
-I/usr/local/include/c-client
-I/home/kalowsky/php/php4/ext/xml/expat/xmltok
-I/home/kalowsky/php/php4/ext/xml/expat/xmlparse
-I/home/kalowsky/php/php4/TSRM -DHARD_SERVER_LIMIT=512
-DDOCUMENT_LOCATION=/usr/local/www/data/
-DDEFAULT_PATH=/bin:/usr/bin:/usr/local/bin -DUSE_EXPAT
-DXML_BYTE_ORDER=12 -g -Wall -c internal_functions.c -fPIC -DPIC -o
internal_functions.lo
In file included from /home/kalowsky/php/php4/ext/imap/php_imap.h:10,
from internal_functions.c:33:
/usr/local/include/rfc822.h:87: redefinition of `soutr_t'
/usr/local/include/c-client/rfc822.h:72: `soutr_t' previously declared
here
/usr/local/include/rfc822.h:89: redefinition of `rfc822out_t'
/usr/local/include/c-client/rfc822.h:74: `rfc822out_t' previously
declared here
*** Error code 1
Stop in /home/kalowsky/php/php4/main.
*** Error code 1
Stop in /home/kalowsky/php/php4/main.
*** Error code 1
Any suggestions to correct this? Or a better way to handle this?
--
Dan Kalowsky "Tonight I think I'll walk alone,
Worldgate Communications I'll find my soul as I go home."
Software Engineer - TICS Group - Temptation
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9343: Causes server to core
From: [EMAIL PROTECTED] Operating system: linux/solaris (been tested with both) PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Causes server to core Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl will cause the server to core (and this only happens with PHP, jserv, mod_roaming... the rest all work). You can simulate the behavior with Apache::Storage. For some reason, when mod_perl goes to access the module's config list inside of Apache, Apache cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem seems to have returned though. -- Edit Bug report at: http://bugs.php.net/?id=9343edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9344: Causes server to core
From: [EMAIL PROTECTED] Operating system: linux/solaris (been tested with both) PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Causes server to core Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl will cause the server to core (and this only happens with PHP, jserv, mod_roaming... the rest all work). You can simulate the behavior with Apache::Storage. For some reason, when mod_perl goes to access the module's config list inside of Apache, Apache cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem seems to have returned though. -- Edit Bug report at: http://bugs.php.net/?id=9344edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9344 Updated: Causes server to core
ID: 9344 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Apache related Assigned To: Comments: submitted twice Previous Comments: --- [2001-02-19 16:12:44] [EMAIL PROTECTED] Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl will cause the server to core (and this only happens with PHP, jserv, mod_roaming... the rest all work). You can simulate the behavior with Apache::Storage. For some reason, when mod_perl goes to access the module's config list inside of Apache, Apache cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem seems to have returned though. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9344edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9345: PHP as subrequests in Apache
From: [EMAIL PROTECTED] Operating system: doens\'t matter PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: PHP as subrequests in Apache Here is the problem, if you make a call to ap_run_sub_req() with a PHP script with a GET method and content length set to zero, PHP will still gobble up whatever is sitting in the socket. This problematic when you don't want PHP to be the script to answer the POST request. I have tried dinking with a number of things (like remaining, length) and such that make up the request_rec, but PHP seems to be ignoring all of them. -- Edit Bug report at: http://bugs.php.net/?id=9345edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9346 Updated:
ID: 9346 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Feature/Change Request Assigned To: Comments: Previous Comments: --- [2001-02-19 17:09:32] [EMAIL PROTECTED] allah belanýzý versin. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9346edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9347: php_read does not handle O_NONBLOCK correctly
From: [EMAIL PROTECTED]
Operating system: linux (mandrake 7.2)
PHP version: 4.0 Latest CVS (19/02/2001)
PHP Bug Type: Sockets related
Bug description: php_read does not handle O_NONBLOCK correctly
The php_read function does not seem to handle non-blocking sockets correctly. The
read function will return a negative value when EAGAIN (no data available when in
nonblocking mode) error occurs. (from the man page:
On error, -1 is returned, and errno is set appropriately.) Here is my quick n' dirty
patch:
--- ext/sockets/mysocket.c Mon Feb 19 16:53:20 2001
+++ ext/sockets/sockets.c Mon Feb 19 16:52:42 2001
@@ -635,7 +635,7 @@
if (m 0) {
t++;
n++;
- } else if (m = 0) {
+ } else if (m == 0) {
no_read++;
if (nonblock no_read = 2) {
return n; /* The first pass, m always is 0, so no_read becomes
1
enjoy.
-tem
--
Edit Bug report at: http://bugs.php.net/?id=9347edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8958 Updated: File uploads append Content-Type string
ID: 8958
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Duplicate
Bug Type: Unknown/Other Function
Assigned To:
Comments:
Duplicate of http://bugs.php.net/bugs.php?id=9298 which is fixed in CVS.
Previous Comments:
---
[2001-02-04 12:40:04] [EMAIL PROTECTED]
I can not reproduce this with latest CVS.
Please try latest CVS snapshot from http://snaps.php.net/
--Jani
---
[2001-01-28 15:29:53] [EMAIL PROTECTED]
Being that it happens to every file uploaded, I don't know how helpful this will be
but..
$file = $HTTP_POST_FILES['file']['tmp_name'];
$file_name = $HTTP_POST_FILES['file']['name'];
@mkdir("../Images/new/$owner",0775);
copy($file,"../Images/new/$owner/$file_name");
Now, the file created has the Content-type: xxx/x plus an additional blank line
at the top of the file.
---
[2001-01-27 20:50:26] [EMAIL PROTECTED]
Please provide a short snippet of code that
reproduces this effect.
---
[2001-01-27 18:20:35] [EMAIL PROTECTED]
Doing file uploads with php 4.0.4pl1 on RH7 (RedHat RPMs) appends the Content-Type:
/x line to the top of the files.
-- Medvitz
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8958edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8940 Updated: File uploads stopped withing in 4.0.4pl1
ID: 8940
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Duplicate
Old-Bug Type: Filesystem function related
Bug Type: Unknown/Other Function
Assigned To:
Comments:
Duplicate of http://bugs.php.net/bugs.php?id=9298 which is fixed in CVS.
Previous Comments:
---
[2001-02-04 12:41:07] [EMAIL PROTECTED]
I can not reproduce this with latest CVS.
Please try the latest CVS snapshot from http://snaps.php.net/
--Jani
---
[2001-01-26 16:07:33] [EMAIL PROTECTED]
If you view the uploaded file (using "od" in my case), you'll see that
the first few bytes of it are:
"Content-Type: image/jpeg" followed by the binary data that makes
up the JPEG file. Since the uploaded file is exactly the same size as
the original, I presume that the last few bytes are dropped out.
---
[2001-01-26 12:50:56] [EMAIL PROTECTED]
Further testing reveals that the upload is working properly, but the
file 'type' variable is not set, and PHP is not treating it as an image
file. Image processing utilities state that the file is corrupt after
uploading, even though it remains the exact same size as the
original. I suspect that PHP is doing something to the file.
---
[2001-01-26 12:01:45] [EMAIL PROTECTED]
Ok, I've done some further testing. With a simple script that does
nothing except upload the file and move it, it works: the file is
there. However, the "type" variable has no value! No matter what
type of file I upload, the $HTTP_POST_FILES['userfile']['type'] value
is an empty string.
---
[2001-01-26 11:21:21] [EMAIL PROTECTED]
I've been using 4.0.3 for a couple of weeks now. Last night I ran the
Redhat Update agent and installed 4.0.4pl1. Everything works fine
except for file uploads. The upload is recorded as successful,
everything SEEMS to work fine, but there is no file in /tmp, and the
variable $HTTP_POST_FILES['userfile']['type'] is undefined. Apache
1.3.14 reports no problems, and returns a 200 return code. I've
tried working with php.ini; I can turn file uploads off, and that
works, then when I turn it back on again, it has the same problem.
I'm pretty sure it's something in 4.0.4pl1 because nothing else on
my system has changed since the upgrade last night. Here's some of
my code:
$file_type = $HTTP_POST_FILES['userfile']['type'];
if (substr($file_type,-4,4) != 'jpeg') {
die( "Files of type '" . $file_type .
"' are not recognized.br" .
"Only JPEG images are currently supported."
);
}
$path_for_file = 'gallery/' . $user_id . '/' . $photo_id .
'.jpg';
if
(!is_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name']))
die( "File is not uploaded." );
move_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name'],
$path_for_file);
...but I really don't think the problem is in the code. Here's some
output from my Apache log file:
192.168.1.2 - - [26/Jan/2001:08:13:04 -0800] "POST /upload.php
HTTP/1.1" 200 51
"http://mysite/upload.php" "Mozilla/4.0 (compatible; MSIE 5.0;
Mac_PowerPC)
"
No errors are reported any where.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8940edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] CVS Account Request
Full name: Lucas Rocha Email: [EMAIL PROTECTED] ID: lucasr Purpose: Contribute with the english-to- portuguese translation of the PHP Manual -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9177 Updated: crypt problems with openssl
Well, I think it's just the link order of libraries. ie. the openssl lib should be before libc..but is that even possible? Or just add another entry for libc after ssl? Might be possible to do some kludge with the link order, I would prefer that OpenSSL changed a bit though, I'll probably have to go nag them again. OpenLDAP needs this to be fixed as well, and I'm sure there are other programs with the same problem. it will not be possible for libc. i have solved similar problem with two conflicting libs thus: gcc -o something -l lib-i-want-to-discard-conflicting-foo ...path/lib-with-preffered-conflicting-foo.so[mething] objects... gnu ld looks in objects tagged for linkage and then in libraries. afaik libc is the last place ld will process and there is no chance to fool it. the best solution is to fix openssl. b. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #7557 Updated: Array stored in session loose content
ID: 7557
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Session related
Assigned To:
Comments:
this is rather a confusion how references work than a bug
if you had var_dump()ed your $session you would have seen
that session handling cannot be involved here
what you are doing is
a) creating a reference $item to an $item in cart1
b) and then storing the whole cart2 therein
chaning (b) to $item = $this-cart2; works for me
Function test() {
for($i=0; $icount($this-cart1); $i++) {
$item = $this-cart1[$i]; // (a)
$item-pid .= "a";
}
$item = $this-cart2; // (b)
for($i=0; $icount($item); $i++) {
$item[$i]-pid .= "a";
}
}
Previous Comments:
---
[2000-12-02 13:23:23] [EMAIL PROTECTED]
Stage 1:
===
Ok, this version works with 4.0.4dev-200012020345. But it was an excerpt from my
code.
Stage 2:
===
Now i have extended the example and got the same error again :-(
Please have a look at the code below:
?
class C_CART_ITEM {
var $pid;
var $id=0;
Function C_CART_ITEM() { }
}
class C_SESSION {
var $cart1 = array();
var $cart2 = array();
Function C_SESSION() { }
Function update() {
$item = new C_CART_ITEM();
$item-pid = "".time();
array_push($this-cart1, $item);
array_push($this-cart2, $item);
}
Function test() {
for($i=0; $icount($this-cart1); $i++) {
$item = $this-cart1[$i];
$item-pid .= "a";
}
$item = $this-cart2;
for($i=0; $icount($item); $i++) {
$item[$i]-pid .= "a";
}
}
Function show() {
echo("ITEMS:BRTABLE CELLSPACING=2 CELLPADDING=0");
$i = 0;
while ($i MAX(count($this-cart1),count($this-cart2))) {
$item = $this-cart1[$i];
$item-id += 1;
echo("TRTD".$item-pid." :".$item-id."/TD");
$item = $this-cart2;
$item[$i]-id += 1;
echo("TD".$item[$i]-pid." :".$item[$i]-id."/TD/TR");
$i++;
}
echo("/TABLEP");
}
}
session_start();
if (!$session) {
$session = new C_SESSION();
session_register("session");
} else {
$session-test();
$session-update();
}
echo "SESSION-ID: ".session_id()."BR";
$session-show();
?
Have a look at the new test function. The line '$item = $this-cart2;' was first a
mistake (it works on a copy and therefore doe not append the 'a' to the pid of other
version). If this line is in there the same old problem is back again.
The output looks like this:
SESSION-ID: f0cf1206f566d170bf6fde86a5f76035
ITEMS:
:975780490 :7
:975780490 :6
:975780491 :5
:975780491 :4
:975780491 :3
:975780491 :2
975780492 :1 975780492 :1
BUT:
If you rename $item with $cart all is ok.
If you replace '$item = $this-cart2;' with '$item = $this-cart2;' all is ok.
Stage 3:
===
I tried a third version with a inc and dec function in the C_CART_ITEM class wich
increased and decreases $id and i called the dec and the inc function in
C_SESSION-test and i got this error:
Fatal error: Call to a member function on a non-object in ...
Ouch!
---
[2000-11-27 08:52:26] [EMAIL PROTECTED]
Should be fixed in CVS. Please try latest snapshot from
http://snaps.php.net/ and reopen this bug report if
this doesn't work with it.
--Jani
---
[2000-11-03 19:32:58] [EMAIL PROTECTED]
works for me (4.0.4dev), please try 4.0.4 as far as it is
out and report results
---
[2000-11-02 03:09:55] [EMAIL PROTECTED]
Every call to the update function in the session class appends a new C_CART_ITEM with
the actual time to the cart1 and cart2 arrays.
If you reload the page several times, you get the following:
SESSION-ID: 970efca9d3effdadf14e679d0e88b349
ITEMS:
973150040 : 1 973150036 : 8
: 1 973150038 : 7
: 1 973150039 : 6
: 1 973150039 : 5
: 1 973150039 : 4
: 1 973150040 : 3
: 1 973150040 : 2
: 1 973150040 : 1
The left two rows show the content of cart1 and the right 2 rows the content of cart2.
Both arrays should have the same content.
cart1 is referenced by item in the show function. And when this is done, this entry is
not available in the next page (after reload etc.).
cart2 is referenced as the whole array - this works.
This bug occurs with PHP versions 4.0.3 (4.0.2 not tested).
It works fine with version 4.0.1pl1 .
[PHP-DEV] PHP 4.0 Bug #9339 Updated: infinite loop in wordwrap
ID: 9339
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Strings related
Assigned To:
Comments:
WFM win32 + linux,
please check out latest CVS and reopen if necessary
Previous Comments:
---
[2001-02-19 12:41:21] [EMAIL PROTECTED]
The following line seems to loop forever:
echo wordwrap("abcdefghijklmnopqr", 10, "rn");
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9339edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9031 Updated: ob_gzhandler memory leak and Headers already sent message!
ID: 9031
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Assigned
Bug Type: Output Control
Assigned To: andre
Comments:
similar Bug id #9231
Previous Comments:
---
[2001-02-06 15:33:49] [EMAIL PROTECTED]
I've just found out what the problem is, and it's kind of weird:
With ob_gzhandler enabled (from php.ini or with ob_start("ob_gzhandler") in the .php)
each readfile() makes the "Cannot add header information - headers already sent" error
message appear.
This doesn't happen with output buffering enabled and no ob_gzhandler, it only happens
with ob_gzhandler enabled.
Also tried to replace readfile with fpassthru(fopen()) but got the same result.
Hope this helps you fix the problem.
If you have any questions feel free to ask, I've been experimenting quite a lot.
---
[2001-02-02 09:23:24] [EMAIL PROTECTED]
Tried the php4-200102020545 snapshot and I still get the
httpd: PHP Warning: Cannot add header information - headers already sent in Unknown
on line 0
error message when enabling output_handler = ob_gzhandler.
This probably still causes a memory leak.
Found another interesting thing: when trying to see the headers of a ob_gzhandler
compressed page with lynx, I get the following lynx error message:
Can't access startfile http://localhost/test.php
That's using lynx -head -source http://localhost/test.php. Seems lynx sees something
which it doesn't like. With ob_gzhandler disabled, I get the normal http headers when
invoking that lynx command.
---
[2001-02-01 20:03:32] [EMAIL PROTECTED]
This should be fixed in CVS now. Please try the latest CVS snapshot from
http://snaps.php.net/ and reopen this bug report if problem still exists when
using it.
--Jani
---
[2001-01-31 09:15:17] [EMAIL PROTECTED]
When enabling output_handler = ob_gzhandler in php.ini, my Linux system starts to eat
more and more memory in an unusual way, like there was a memory leak, like many people
have reported.
But what is absolutely weird is that after enabling ob_gzhandler, I start to get this
error messages in my log files:
Cannot add header information - headers already sent in Unknown on line 0
Which is weird, because one of the features of output buffering is to avoid that kind
of problems. What's even more weird is that I don't get any "headers already sent"
messages with output_handler = ob_gzhandler disabled!
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9031edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9231 Updated: when usign ob_gzhandler HTTP HEAD does not work
ID: 9231 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Assigned Bug Type: Output Control Assigned To: andre Comments: similar to Bug id #9031 Previous Comments: --- [2001-02-17 11:51:19] [EMAIL PROTECTED] reopened --- [2001-02-17 11:50:18] [EMAIL PROTECTED] HTTP-1.0 and HTTP/1.0 are just the same for apache this bug report says that ob_gzhandler crashes HEAD requests when php is an apache module --- [2001-02-14 12:25:12] [EMAIL PROTECTED] shouldn't it reaad HEAD / HTTP/1.0 bogus --- [2001-02-12 15:05:20] [EMAIL PROTECTED] php.ini: output_handler = ob_gzhandler tests: a plain html request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 HTTP/1.1 200 OK Date: Mon, 12 Feb 2001 19:57:47 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT ETag: "ac04-1f6-3a2b95af" Accept-Ranges: bytes Content-Length: 502 Connection: close Content-Type: text/html Connection closed by foreign host. php script request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 host: mail.bonev.com same php script, but now GET instead of HEAD: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. GET / HTTP/1.0 host: mail.bonev.com HTTP/1.1 302 Found Date: Mon, 12 Feb 2001 19:57:22 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev X-Powered-By: PHP/4.0.5-dev location: /6bcf63364235c745643078ff1e0df2d6/ Connection: close Content-Type: text/html Connection closed by foreign host. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9231edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8923 Updated: Serious bug -- Memory leak in gzencode() function
ID: 8923 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Output Control Assigned To: Comments: this one should be fixed in CVS, please reopen if it is not Previous Comments: --- [2001-01-30 04:38:30] [EMAIL PROTECTED] reclassified. --- [2001-01-25 21:03:15] [EMAIL PROTECTED] I was using Web Application Stress Tool when I discovered this bug in zlib. Under load, php would keep using up more and more memory. I found that the gzencode() function was causing the problem. I was using gzencode() to enable http-compression in my pages. Commenting out gzencode() and disabling http-compression seemed to have resolved the problem. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8923edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9231 Updated: when usign ob_gzhandler HTTP HEAD does not work
ID: 9231 User Update by: [EMAIL PROTECTED] Status: Assigned Bug Type: Output Control Description: when usign ob_gzhandler HTTP HEAD does not work yep. both seem to be apache SAPI module problem related to ob in general (at least i suppose so) Previous Comments: --- [2001-02-19 23:03:00] [EMAIL PROTECTED] similar to Bug id #9031 --- [2001-02-17 11:51:19] [EMAIL PROTECTED] reopened --- [2001-02-17 11:50:18] [EMAIL PROTECTED] HTTP-1.0 and HTTP/1.0 are just the same for apache this bug report says that ob_gzhandler crashes HEAD requests when php is an apache module --- [2001-02-14 12:25:12] [EMAIL PROTECTED] shouldn't it reaad HEAD / HTTP/1.0 bogus --- [2001-02-12 15:05:20] [EMAIL PROTECTED] php.ini: output_handler = ob_gzhandler tests: a plain html request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 HTTP/1.1 200 OK Date: Mon, 12 Feb 2001 19:57:47 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT ETag: "ac04-1f6-3a2b95af" Accept-Ranges: bytes Content-Length: 502 Connection: close Content-Type: text/html Connection closed by foreign host. php script request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 host: mail.bonev.com same php script, but now GET instead of HEAD: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. GET / HTTP/1.0 host: mail.bonev.com HTTP/1.1 302 Found Date: Mon, 12 Feb 2001 19:57:22 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev X-Powered-By: PHP/4.0.5-dev location: /6bcf63364235c745643078ff1e0df2d6/ Connection: close Content-Type: text/html Connection closed by foreign host. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=9231 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8536 Updated: ob_start() is not working with virtual() function
ID: 8536 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Assigned Bug Type: Output Control Assigned To: andre Comments: in php_apache.c (line 324) if have found the following php_end_ob_buffers(1); php_header(); I guess this is intended to avoid some confusion with sent headers, but if we (have to) close all buffers it should be mentioned in the documentation (at least) anyway I do not really understand this drastic closure of open buffers Previous Comments: --- [2001-01-03 10:48:03] [EMAIL PROTECTED] Output of virtual() function didn't seem to work with ob_start() function. Is there any way to store the output of virtual()? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8536edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] php_apache.c virtual() enlightment needed
I tried (and failed) to figure out why virtual() closes any output buffers, I think this is not very gentle, could anybody enlighten me? andr -- Andr Langhorstt: +49 331 5811560 [EMAIL PROTECTED] m: +49 173 9558736 * PHP Quality Assurance http://qa.php.net * ID: 8536 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Assigned Bug Type: Output Control Assigned To: andre Comments: in php_apache.c (line 324) if have found the following php_end_ob_buffers(1); php_header(); I guess this is intended to avoid some confusion with sent headers, but if we (have to) close all buffers it should be mentioned in the documentation (at least) anyway I do not really understand this drastic closure of open buffers Previous Comments: --- [2001-01-03 10:48:03] [EMAIL PROTECTED] Output of virtual() function didn't seem to work with ob_start() function. Is there any way to store the output of virtual()? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8536edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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] Time for 4.0.5?
I want to fix chunked output buffering for 4.0.5 (it doesn't work right at all in 4.0.4). I think it'll take me about 10 days (I'll probably not have time to work on it this week). About bzip2 - my personal opinion is that we should probably not bother with it. It's slower and it's much less standard (there's a world beyond Linux, remember). We definitely can't give up our .tar.gz/.zip distros, because these are the standard ways of distributing apps on the net and people would expect them. Given that, I don't think that adding .bz2 is going to be much more helpful than cluttering the download page... That's just my opinion though. 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] Time for 4.0.5?
I want to fix chunked output buffering for 4.0.5 (it doesn't work right at all in 4.0.4). I think it'll take me about 10 days (I'll probably not have time to work on it this week). glad to hear this, I think this is *definitely* worth waiting... :) andr -- Andr Langhorstt: +49 331 5811560 [EMAIL PROTECTED] m: +49 173 9558736 * PHP Quality Assurance http://qa.php.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] PHP 4.0 Bug #9194 Updated: Objects not properly stored as session variables
ID: 9194 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Class/Object related Assigned To: andre Comments: Please provide a reduced code fragment (15 lines) producing this behaviour. Put no database queries etc. in it and rely on no external files/functions to ensure that we can reproduce it easily unless the problem is not directly related to some db (or similar) function. Previous Comments: --- [2001-02-09 11:00:20] [EMAIL PROTECTED] Look at http://mail2.anduin.net/index.phps for sourcecode of failing page. http://mail2.anduin.net/index.php to test, use test/test as username/password. Bug is as follows: I define the class "user", call session_start(), create an instance of the object called $currentuser, register this variable using session_register() (i tried doing this both before and after the instancination). Upon creating, the object sets some internal variables in its constructor, like "fullname". When loading the page again, having the session-id in PHPSESSID, the object shows up as existing, but trying to call a method or view a property fails with the message: Fatal error: The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition user of the object you are trying to operate on was loaded _before_ the session was started in /home/ltning/webmail2/index.php on line 34 I see this bug has been reported before and considered fixed, but it doesn't seem to be. Running latest (4.04pl1) PHP. best regards, Eirik Overby --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9194edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
At 07:51 20/2/2001, Emiliano wrote: Zeev Suraski wrote: About bzip2 - my personal opinion is that we should probably not bother with it. It's slower and it's much less standard (there's a world beyond Linux, remember). I have it on the BSDs and Solaris too. But most people don't. It doesn't come in as a standard in most operating systems. 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] Time for 4.0.5?
I'm not sure what all has been suggested, so sorry if this has been already. Why not just make a simple form and avoid clutter completely? (ie all the links) Could allow them to choose source/binary, os, PHP version, compression format, etc. Chris Newbill Zeev Suraski wrote: About bzip2 - my personal opinion is that we should probably not bother with it. It's slower and it's much less standard (there's a world beyond Linux, remember). We definitely can't give up our .tar.gz/.zip distros, because these are the standard ways of distributing apps on the net and people would expect them. Given that, I don't think that adding .bz2 is going to be much more helpful than cluttering the download page... That's just my opinion though. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9331 Updated: No operator overloading available
ID: 9331
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Suspended
Bug Type: Feature/Change Request
Assigned To:
Comments:
I hardly believe this will be implemented anytime soon or
accepted at all,
suspending (for the records)
Previous Comments:
---
[2001-02-19 02:07:25] [EMAIL PROTECTED]
It would be nice to have operator overloading available for
classes. Something along the lines of Perl and C++. I'm
sure there are other OO languages that provide similar
functionality. This would go a long way to allowing the
creation of object classes that are similar to those built
into the language.
At least one class I'm wanting to create that could use this
is an ordered set -- use +,-,*,/ for set union, asymmetric
difference, intersection, and difference, for example.
Perhaps borrowing the C++ syntax wouldn't be a great burden.
function operator+(objectClass,objectClass) { ... }
Unfortunately, this would require prototyping of class
methods, but this is already implicately done for the
operators (as far as the coder is concerned, even if not in
fact).
Perhaps one way around the need for an explicit prototype is
to consider the first argument of the binary operation (the
left operand) as the governing class for finding the method.
Then $A+$B == $A-operator+($B) and the function declaration
is reduced to
class A {
function operator+($B) { ... }
}
I think this is important enough to the development of the
language, and I didn't find mention of it in any of the
documentation or archives I searched, that I am submitting
it as a bug report for t
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9331edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9084 Updated: url-activation for simple URLs
ID: 9084 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Analyzed Bug Type: Feature/Change Request Assigned To: Comments: 1) implemented in PEAR 2) not sure whether this should be implemented in PEAR or PHP, we have get_meta and so on, str_add_anchors() would not hurt, but maybe not suffice to put in the core Previous Comments: --- [2001-02-02 19:34:09] [EMAIL PROTECTED] I miss two functions in PHP. I believe they should be added to the URL functions if added. 1. "E-Mail ereg validation" function. 2. "Enable all urls in a text" function. (Enable means add html tags so they will be clickable). Today I'm using these PHP coded functions: http://www.zend.com/search_code_author.php?author=russlndr Thats works fine, but I think they should included as a part of PHP. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9084edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9086 Updated: auto trans-sid and output_handler
ID: 9086 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Feature/Change Request Assigned To: Comments: this should be covered by the "trans-sid as output handler" RFE Previous Comments: --- [2001-02-03 10:33:51] [EMAIL PROTECTED] Sessions auto trans-sid are not working if you enable the content compression ( output_handler = ob_gzhandler ; in the php.ini ) Here is the output of my configure line : './configure' '--prefix=/usr/local/php' '--with-config-file-path=/usr/local/apache/php/conf' '--enable-ftp' '--enable-magic-quotes' '--enable-track-vars' '--with-regex=system' '--enable-trans-sid' '--disable-debug' '--enable-pic' '--enable-inline-optimization' '--with-zlib' '--with-config-file-path=/etc' '--with-xml' '--without-mysql' '--with-apxs=/usr/local/apache/bin/apxs' --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9086edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /win32 php4dllts.dsp
Zeev Suraski wrote:
zeevMon Feb 19 21:14:33 2001 EDT
Modified files:
/php4/win32 php4dllts.dsp
Log:
Restore COM.c
COM.c
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(62) : error
C2059: Syntaxfehler : 'string'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(6) :
error C2143: Syntaxfehler : Fehlendes ')' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(6) :
error C2143: Syntaxfehler : Fehlendes '{' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(6) :
error C2143: Syntaxfehler : Fehlendes ';' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(6) :
error C2059: Syntaxfehler : 'type'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(6) :
error C2059: Syntaxfehler : ')'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(7) :
error C2143: Syntaxfehler : Fehlendes ')' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(7) :
error C2143: Syntaxfehler : Fehlendes '{' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(7) :
error C2143: Syntaxfehler : Fehlendes ';' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(7) :
error C2143: Syntaxfehler : Fehlendes ';' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(7) :
error C2059: Syntaxfehler : 'type'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(7) :
error C2059: Syntaxfehler : ')'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(8) :
error C2143: Syntaxfehler : Fehlendes ')' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(8) :
error C2143: Syntaxfehler : Fehlendes '{' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(8) :
error C2143: Syntaxfehler : Fehlendes ';' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(8) :
error C2059: Syntaxfehler : 'type'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(8) :
error C2059: Syntaxfehler : ')'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(9) :
error C2143: Syntaxfehler : Fehlendes '{' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(9) :
error C2146: Syntaxfehler : Fehlendes ')' vor Bezeichner 'strlen'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(9) :
error C2081: 'uint' : Name in der formalen Parameterliste ist ungueltig
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(9) :
error C2061: Syntaxfehler : Bezeichner 'strlen'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(9) :
error C2059: Syntaxfehler : ';'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(9) :
error C2059: Syntaxfehler : ','
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(9) :
error C2059: Syntaxfehler : ')'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(10) :
error C2143: Syntaxfehler : Fehlendes ')' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(10) :
error C2143: Syntaxfehler : Fehlendes '{' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(10) :
error C2143: Syntaxfehler : Fehlendes ';' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(10) :
error C2059: Syntaxfehler : 'type'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\conversion.h(10) :
error C2059: Syntaxfehler : ')'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(74) : error
C2061: Syntaxfehler : Bezeichner 'com_class_entry'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(74) : error
C2059: Syntaxfehler : ';'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(78) : error
C2143: Syntaxfehler : Fehlendes ')' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(78) : error
C2081: 'zval' : Name in der formalen Parameterliste ist ungueltig
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(78) : error
C2143: Syntaxfehler : Fehlendes '{' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(78) : error
C2143: Syntaxfehler : Fehlendes ';' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(78) : error
C2059: Syntaxfehler : 'type'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(78) : error
C2059: Syntaxfehler : ')'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(79) : error
C2143: Syntaxfehler : Fehlendes ')' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(79) : error
C2081: 'zval' : Name in der formalen Parameterliste ist ungueltig
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(79) : error
C2143: Syntaxfehler : Fehlendes '{' vor '*'
D:\Programme\MS Visual Studio\Projekte\php\php4\ext\com\COM.c(79) : error
C2143: Syntaxfehler : Fehlendes ';' vor '*'
[PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault
ID: 9136
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Analyzed
Bug Type: Feature/Change Request
Assigned To:
Comments:
Previous Comments:
---
[2001-02-06 17:41:12] [EMAIL PROTECTED]
maybe we should move this to feature request for safe mode?
it would be fine to give the server owner the possibility to
autokill scripts which would kill the server in a few
microseconds, shouldn't it be implementable without loosing
performance, check the level the stack is filled up against
a values in php.ini maybe...
---
[2001-02-06 17:31:02] [EMAIL PROTECTED]
and guess this "bug" was present in any version before, what
do you expect to happen here? you will never leave these
function calls (as you know I guess), as far as your stack
is full it is full
remember php has to remember each and every function call it
did...
a()
b()
a()
b()
if you really need exactly this construct, I would suggest
you to use a static variable to count the total function
calls and find the critical values a specific system
segfaults (with your original code), then you stick a
for(;;) around it and implement a check (eg. in a()) against
the static variable to leave the recursion if a value with
enough distance to the critical value is reached, then you
should be able to begin the recursion again
any recursion can be displayed as a loop, do not use
recursion if you want to recurse infinitely
---
[2001-02-06 17:22:36] [EMAIL PROTECTED]
PHP doesn't handle infinite recursion, and as earlier was discussed on the php-dev
list, it wont be implemented to guard for this, because of the high performance impact.
---
[2001-02-06 17:18:03] [EMAIL PROTECTED]
---
%
function a () {
b();
}
function b () {
a();
}
a();
%
h1done/h1
-
The simple script above causes a seg fault. If you need more info on configuration
etc please mail me. We made this simple example from a more compilcated instance.
This bug was also present in 4.0.3pl1, we upgraded to try and stop the seg fault...
thanks!
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9136edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #3275 Updated: [PEAR] ICQ support
ID: 3275 Updated by: andre Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Assigned To: Comments: adding PEAR keyword, that would be a typical C extension for PEAR Previous Comments: --- [2001-02-10 13:59:13] [EMAIL PROTECTED] refiling against 4.0. --- [2000-01-22 00:43:23] [EMAIL PROTECTED] Please add support to connect and collect messages from ICQ servers either using libicq or icqlib: icqlib http://kicq.sourceforge.net/icqlib.shtml libicq http://www.korsoft.com/gicq/ --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=3275edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8978 Updated: Add a 'readonly' possibility to the session module
ID: 8978 Updated by: andre Reported By: Maxim Derkachev [EMAIL PROTECTED] Old-Status: Open Status: Analyzed Bug Type: Feature/Change Request Assigned To: Comments: Previous Comments: --- [2001-01-29 06:21:31] Maxim Derkachev [EMAIL PROTECTED] Just faced the fact that the possibility to call session 'readonly' should be added. For example, when somebody calls a framed pages where all frames are php scripts that needs session variables. But in this case only one of them should be allowed to write session state, because every frame would write session state in an unpredictable order, and variables registered/changed in one frame could be overwritten by other frames, and that would definitely break an application. I suggest session_start could take an optional READONLY flag to disable write of the session data during the page shutdown. The idea is similar to call page_close() on only one frame in a framed page in PHPLib-based applications. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8978edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9099 Updated: please include one browscap.ini
ID: 9099 Updated by: andre Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Assigned Bug Type: Feature/Change Request Assigned To: andre Comments: AFAIK, we are not allowed to include the cyscape one, but there is another one out there, I am sure we have discussed it some day before and I gathered the permission to include the asptrackers one (http://marc.theaimsgroup.com/?l=php-devm=96453774821265w=2), but I do not remember if we did or not? anybody with better mnemonics? Previous Comments: --- [2001-02-04 09:42:07] [EMAIL PROTECTED] The browscap.ini was there in the 4.0.3pl1 version, but is missing from the 4.0.4pl1 windows zip distribution. It was a great idea to put browscap.ini in the distribution, so please do not drop it out!!! --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9099edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9237 Updated: date function parameters won't work on PWS
ID: 9237
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Date/time related
Description: date function parameters won't work on PWS
Yes, the message I received is like this ...
I didn't receive that before.
Suggestions: don't set error reporting by default so high in installation wizard for
win32 binaries.
Thanx,
Andris
Previous Comments:
---
[2001-02-13 12:44:48] [EMAIL PROTECTED]
I bet the text of the errmsg is somethign like this:
Warning: Use of undefined constant x - assumed 'x' in ... on line ...
this is caused by error_reporting set high enough to trigger this warning.
---
[2001-02-13 05:26:30] [EMAIL PROTECTED]
On linux (built in) and IIS 4.0 (cgi vers) on nt4.0 wrkst i can use function for
example:
function getThisMonth(){
$dat=getdate();
return $dat[mon];
}
without problem.
On pws it reproduces error (description I don't remember - it happens at home)
I should put mon in double quotes '"'. Then it works.
This error happens with other parameters like nmon, year ...
With quotes it works on linux and IIS 4.0 too.
Thanks,
Andris
---
Full Bug description available at: http://bugs.php.net/?id=9237
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9350: Internet Time Incorect
From: [EMAIL PROTECTED]
Operating system: Windows 2000 (IIS5)
PHP version: 4.0.4pl1
PHP Bug Type: Date/time related
Bug description: Internet Time Incorect
I used this script:
?
$ServerTime = time();
$SerTime = date('g:i:s a',$ServerTime);
$SerLongDate = date('l, dS F Y',$ServerTime);
$SerBeat = date("@B",$ServerTime);
Print "bServerTime:/b $SerTimebrbServerLongDate:/b
$SerLongDatebrbServerSwatch:/b $SerBeatbr";
?
The internet time shows correctly except for the first hour (or 42 beats)
From @000 onwards it does not count up 001, 002, 003 etc untill 1 hour has passed and
it then shows @042.
Is this a bug with PHP or Windows 2000. ALso if it is PHP is it just Win32 or the unix
version also.
--
Edit Bug report at: http://bugs.php.net/?id=9350edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9349 Updated: Coding problem in mod_dav module
ID: 9349 User Update by: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Failure Description: Coding problem in mod_dav module Sorry! Finally found the early report regarding this problem. It was in BugID: 7943 The URL is: http://bugs.php.net/bugs.php?id=7943 Regards, KC Previous Comments: --- [2001-02-20 02:29:11] [EMAIL PROTECTED] There are 3 problems when enable the mod_dav module: 1. undefine data type "request_rec" in "ext/dav/php_dav.h" possible solution: add "#include httpd.h" 2. parsing error in "ext/dav/dav.c" line 153 reason: an extra ";" at the end of line possible solution: Remove the ";" at the end of line 3. wrong arguement in "sapi/apache/mod_php4.c" line 749 reason: "send_php" only take 3 args but the code give 4 possible solution: Remove the extra arg ", 0" Regards, KC Lau --- Full Bug description available at: http://bugs.php.net/?id=9349 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9350 Updated: Internet Time Incorect
ID: 9350
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Date/time related
Assigned To:
Comments:
I think was fixed in CVS, could you try a snapshot from snaps.php.net ans reopen this
bugreport when it doesn't solve the problem?
Previous Comments:
---
[2001-02-20 02:37:04] [EMAIL PROTECTED]
I used this script:
?
$ServerTime = time();
$SerTime = date('g:i:s a',$ServerTime);
$SerLongDate = date('l, dS F Y',$ServerTime);
$SerBeat = date("@B",$ServerTime);
Print "bServerTime:/b $SerTimebrbServerLongDate:/b
$SerLongDatebrbServerSwatch:/b $SerBeatbr";
?
The internet time shows correctly except for the first hour (or 42 beats)
From @000 onwards it does not count up 001, 002, 003 etc untill 1 hour has passed and
it then shows @042.
Is this a bug with PHP or Windows 2000. ALso if it is PHP is it just Win32 or the unix
version also.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9350edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: PHP 4.0 Bug #9350 Updated: Internet Time Incorect
On Tue, 20 Feb 2001, Shaun Williams wrote: I don't understand. I am only just learning PHP and what is this CVS stuff...what is a snapshot??? CVS is a system in which we manage the source of PHP, that should not be of any concern to you. Every hour or so, the PHP source is packaged as a snapshot which is a full distribution of the source, just like a php-4.0.4pl1 release. This snapshot you can get from snaps.php.net for you to download and compile. If you don't know how to compile, please ask your sysadm about it. 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]
