[PHP-DEV] RC3
Finally, it's out. www.php.net/~zeev/php-4.0.7RC3.tar.gz -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] usort won't work anymore on 408dev - zend_hash.c b ug?
Fixed - thanks!
At 14:17 04-10-01, Marc Boeren wrote:
So it seems the results are sorted, but the keys aren't reassigned...
If I track the source, I find the zend_hash_sort function in zend_hash.c has
changed between 407 and 408:
407:
if (renumber) {
p = ht-pListHead;
i=0;
while (p != NULL) {
p-nKeyLength = 0;
p-h = i++;
p = p-pListNext;
}
ht-nNextFreeElement = i;
zend_hash_rehash(ht);
}
408:
if (renumber) {
p = ht-pListHead;
i=0;
while (p != NULL) {
p-nKeyLength = 0;
;
p = p-pListNext;
}
ht-nNextFreeElement = i;
zend_hash_rehash(ht);
}
If I restore the
p-h = i++;
line, everything works again...
Cheerio, Marc.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: RC3
At 09:00 05-10-01, Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Zeev Suraski wrote: Finally, it's out. www.php.net/~zeev/php-4.0.7RC3.tar.gz In addition to previous problem, CGI build seems to print following line again.. X-Powered-By: PHP/4.0.7RC3 Content-type: text/html I saw this line in phpinfo(). % php -i info.html % mozilla info.html OS: Kondara 2.0/Linux 2.4.4/glibc 2.2.2 (This distribution is mostly the same as RedHat 7.1) BTW, I build CGI version with much less options (./configure --enable-debug) PHP does not segfault at the end of test script execution. Can you do a 'binary search' and find out which option causes PHP to crash? The backtrace is pretty meaningless :I 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] user_error trucates at 1KB?
As a temporary solution, you can edit Zend/zend.c, search for ZEND_ERROR_BUFFER_SIZE, and increase the buffer size. It's not a very good solution though, so it won't be merged in to the general distribution. We'll try to make it work better in a future release. Zeev At 04:09 05-10-01, Siggy wrote: Is there a way to increase the length the error message string givento user_error ? It appears that it is limited to about one kilobyte; which is generally fine, except if you want to dump alot of information through it, (eg all variables set, other debugging info establishin what the client is doing in the program, complicated sql queries [which are morelikely to fail... :P ], states of files and so on), it is truncated...Am i forced to update my error logging routines to circumvent this limitation, shy of updating the php source code? :P Using PHP404pl1 on Redhat 7.1 Siggy -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: RC3
Try going to the images' URLs (take them from the img tags) and see what happens. It's best if you go there using pure HTTP (telnet to port 80), or wget. It may shed some light on what's going wrong... At 10:25 05-10-01, Yasuo Ohgaki wrote: Ok, it may depends on how PHP is configured. I'll try different configureations later. If you would like to see how it look like, please let me know off list. I'll send image directly. -- Yasuo Ohgaki Phil Driscoll wrote: On Friday 05 October 2001 9:02 am, Hellekin O. Wolf wrote: At 16:31 05/10/2001 +0900, Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Zeev Suraski wrote: Finally, it's out. www.php.net/~zeev/php-4.0.7RC3.tar.gz In addition to previous problem, CGI build seems to print following line again.. Minor problems with phpinfo() while running PHP as Apache module. Logo images(PHP/Zend) are not displayed. *** I don't have those problems. Can you reproduce ? Likewise - all logos are there for me while running PHP as Apache module. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Security e-mail address
At 04:36 06-10-01, Rasmus Lerdorf wrote: Jani said: Excellent idea. This is exactly something we really need. A private address which is not limited to 10 persons or so. What did Linus say again..enough eyes and all bugs are..something? I'm really not all that worried about having the ability to fix issues in the small group or at least understanding the issue and bringing in the appropriate people privately to come up with a fix. So the number of people receiving that initial email really doesn't worry me. Heck it could be a single person we designate to be the security officer and rotate that responsibility. It isn't that hard to figure out who wrote a specific piece and if you have been around a while you know the people who are likely to be able to provide some insight. The number of people who get to see it does worry me - it has to be reasonably small to be manageable, which is why I think that the way it works today is pretty good (such reports go to group@, adding [EMAIL PROTECTED] is a good idea too, I don't like the security-officer idea too much though). This can't be an open-forum such as php-dev either, for obvious reasons. The 'enough eyeballs' rule doesn't apply here, at least it doesn't apply in many cases. If something is safe enough to be sent out in the open in php-dev, no problem. If it's a bad bug, e.g., a remotely exploitable bug, fixing it silently, involving only the people who are related to the faulty code, is probably the best practice. 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] Forcing trans_sid on?
It could be a bug introduced by my patches from a couple of months ago
(even though this behavior may have existed before, I'm not sure). I, at
least, wasn't giving any thought to people who want to emit out SID's on
their own.
At 03:42 18-10-01, Rasmus Lerdorf wrote:
This code in session.c looks odd to me:
if (!PS(use_cookies) send_cookie) {
PS(apply_trans_sid) = 1;
send_cookie = 0;
}
Basically what this says is that if session.use_cookies is off, trans_sid
will be automatically used regardless of the session.use_trans_sid
setting. This doesn't make sense to me. If I specially turn off
use_cookies and trans_sid in my php.ini file because I want to control
things using my own ?=SID? tags trans_sid getting forced on screws me
over because it will add a second PHPSESSION=. to every link. It
won't break my app, since multiply-defining the session id is ok, but it
sure makes my urls ugly.
What was the logic behind forcing trans_sid on in that case instead of
using the current trans_sid setting?
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.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] New zend_compile.c to solve all of the duplicate function problems
Nope, Edin was right. It's valid in both senses.
Zeev
At 11:50 19-10-01, Rasmus Lerdorf wrote:
It is valid in the sense that the code would not be executed the second
time, but it isn't valid for preventing multiple function definitions
inside that block. ie. no conditional function definitions.
-Rasmus
On Fri, 19 Oct 2001, Edin Kadribasic wrote:
Since you can no longer do:
if(!defined(_FOO_INC)):
define('_FOO_INC',1);
...
endif;
to protect a file from multiple inclusion within the file itself, some
This is still a valid construct. I could find nothing in the discussion
that
would indicate otherwise. The only thing that does not work now, and it did
before was:
if(!defined(_FOO_INC)):
define('_FOO_INC',1);
return;
endif;
...
...
--
PHP Development Mailing List http://www.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] New zend_compile.c to solve all of the duplicate function problems
Clearly, you shouldn't be getting function redefinitions with the way you
wrote the code. I'm not sure why Rasmus is getting them, Rasmus - are you
sure you're running an exact copypaste of his code?
Basically, unless the functions are in the top-level scope, there won't be
any problems, because their definitions is delayed until run-time. Since
they're within an if block, there should be no problems.
That said, I've been thinking about it for almost a day now, and I don't
see any overwhelmingly-serious problems with the patch Brian
suggested. Problems I do see:
- Even with no protection at all, function redefinitions will not be
reported. That's kind of ugly.
- Won't work with URL includes (didn't look that one up thoroughly).
I'm still in favour of reverting to the old 4.0.6 behavior for now, and
sorting it out in 4.2.0, rather than 4.1.0.
Zeev
At 12:52 19-10-01, Edin Kadribasic wrote:
I guess I do not understand. The following example works just fine in
PHP
4.1.0RC1:
test.php
=
?php
include 'testlib.php';
include 'testlib.php';
test();
?
testlib.php
==
?php
if (!defined('_TESTLIB_PHP')) {
define ('_TESTLIB_PHP', 1);
function test() {
print Function test()\n;
}
}
?
Doesn't work in my 4.1 here. I get redefined function errors.
Now that's totally weird. I get output like this:
[ek@scpno test]$ ../php -v
4.1.0RC1
[ek@scpno test]$ ../php -q test.php
Function test()
Can anyone reproduce this?
Edin
--
PHP Development Mailing List http://www.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] New zend_compile.c to solve all of the duplicate function problems
At 16:33 19-10-01, Daniel Beckham wrote: The reason it works inside of an if/endif is because the code is never pre-compiled and only executed during run time. For large code libraries, like we have here at our office, this would cause a performance decrease. The code is precompiled alright. It's just compiled into slightly worse intermediate code, because no compile-time binding can be done. I don't expect the difference to be more than a few percent away, and altogether, it may not be noticeable at all. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems
At 17:47 19-10-01, Brian Moon wrote:
It is in fact slightly faster. I created a script with 10 functions
like:
function foo1() { echo 1; }
It was 3.3 seconds to 3.6 seconds in favor of the patched code.
That's like comparing apples and palm trees though, because the behavior
was different...
Anyway, can you please send me a unified diff of this patch? Walking over
the context diff is very annoying :)
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] New zend_compile.c to solve all of the duplicate function problems
At 23:58 20-10-01, Stanislav Malyshev wrote: DB My argument is that some functionality similar to a C #ifdef and DB #ifndef is needed. Neither the include_once() nor the if/endif Tell me how, for example, Java or Perl programmers manage to live without ifdefs. At least as far as Java is concerned, it's quite a limiting issue. The fact Java has no preprocessor directives sucks quite a lot in my opinion. However, I do not buy into the argument that PHP should have them, because in order to do it the right way, it's going to require a whole new pass of parsing. This is something you can afford with C, but cannot afford with PHP. 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] New zend_compile.c to solve all of the duplicate function problems
At 19:11 19-10-01, Brian Moon wrote: - Even with no protection at all, function redefinitions will not be reported. That's kind of ugly. An E_NOTICE is raised at runtime. I know many people ignore these, but it is there. So basically, your existing code base will now be issuing tons of E_NOTICE's? How about if we introduce an implicit _once directive? Do you have cases in which you intentionally include the same file twice? 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] Does PHP allow $obj-get(this)-set(hello);
No, it doesn't. A future version will...
At 19:10 21-10-01, Geoff Hibble wrote:
Help, I get a syntax error on
$obj-get(this)-set(hello);
where
class H {
var $v = null;
function H () {
}
function set($val) {
$this-v = $val;
}
}
class OBJ {
var $a = null;
function OBJ() {
$this-a = array();
}
function get($name) {
return $this-a[$name];
}
function add($name,$object) {
$this-a[$name] = $object;
}
}
$obj = new OBJ();
$obj-add(this, new H());
$obj-get(this)-set(hello);
-
Does PHP allow this?
Why / Why Not?
Thanks
--
PHP Development Mailing List http://www.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] Zend Optimizer
Nope, it's incompatible because there were lots of binary changes in this version... Mail me your platform though, and I'll send you a snapshot by Email. Zeev At 21:59 21-10-01, Mike Rogers wrote: Guys; Is there any way to get the Zend Optimizer to work with the latest CVS snapshot. I really need it working and can't go backwards because I would break why I am using a snapshot in the first place. Any ideas? -- Mike -- PHP Development Mailing List http://www.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] command-line debugging broken?
It's a very old bug, it even has an open entry in the bugs
database. Haven't thought of a good solution for it...
At 01:19 23-10-01, Rasmus Lerdorf wrote:
An update to this. It only happens if an extension is dl()'ed. If it is
loaded via an extension= in php.ini it works fine.
-Rasmus
On Mon, 22 Oct 2001, Rasmus Lerdorf wrote:
The leak notices and other --enable-debug messages seem to be brokwn right
now.
ie.
stick a stray char *s = emalloc(20); somewhere and try running php
script.php from the command line. I get a segfault that looks like this:
#0 0x406ab75c in _IO_vfprintf (s=0xbfffeca0, format=0x8186e40 %s(%d) :
Freeing 0x%.8lX (%d bytes), script=%s\n,
ap=0xbfffedd0) at ../sysdeps/i386/i486/bits/string.h:530
#1 0x406cc615 in _IO_vsnprintf (string=0xb010 , maxlen=512,
format=0x8186e40 %s(%d) : Freeing 0x%.8lX (%d bytes),
script=%s\n, args=0xbfffedcc) at vsnprintf.c:131
#2 0x406b3afb in __snprintf (s=0xb010 , maxlen=512,
format=0x8186e40 %s(%d) : Freeing 0x%.8lX (%d bytes),
script=%s\n) at snprintf.c:37
#3 0x0806f0b3 in php_message_handler_for_zend (message=4,
data=0x827b560) at main.c:582
#4 0x08145fab in zend_message_dispatcher (message=4, data=0x827b560)
at zend.c:616
#5 0x08135fd5 in shutdown_memory_manager (silent=0, clean_cache=0) at
zend_alloc.c:502
#6 0x0806f75e in php_request_shutdown (dummy=0x0) at main.c:743
#7 0x0806e096 in main (argc=2, argv=0xb934) at cgi_main.c:775
#8 0x406706b7 in __libc_start_main (main=0x806d62c main, argc=2,
ubp_av=0xb934, init=0x8069ee4 _init,
fini=0x8185db0 _fini, rtld_fini=0x4000db64 _dl_fini,
stack_end=0xb92c)
at ../sysdeps/generic/libc-start.c:129
(gdb) up
#3 0x0806f0b3 in php_message_handler_for_zend (message=4, data=0x827b560)
at main.c:582
582 snprintf(memory_leak_buf, 512, %s(%d) :
Freeing 0x%.8lX (%d bytes), script=%s\n, t-filename, t-lineno,
(unsigned long)ptr, t-size, SAFE_FILENAME(SG(request_info).path_translated));
(gdb) p *t
$2 = {magic = 1930623196, filename = 0x40017cab Address 0x40017cab out
of bounds, lineno = 123, reported = 0,
orig_filename = 0x0, orig_lineno = 0, pNext = 0x827b4e0, pLast = 0x0,
size = 20, persistent = 0, cached = 0}
That mem_header looks a bit messed up. I could of course be stepping on
memory elsewhere. Anybody else seeing this?
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.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] startup sequencing issue with php_admin_value disable_functions?
At 09:01 24-10-01, Edin Kadribasic wrote: At 07:55 24-10-01, Rasmus Lerdorf wrote: php_admin_value disable_functions does not work. Works fine from php.ini. It's not supposed to work, it can only work from php.ini. Shouldn't php_admin_value work in VirtualHost part of httpd.conf? It seems that there is something broken there. See bug reports #12748, #13633 and #13803. It's not related really. These bugs appear to suggest there's an issue with the URL fopen system. From a quick glance, it appears that if php.ini has URL fopens disabled, the URL fopen system does not initialize itself. So, turning it on anywhere else is not going to work, but is going to crash. 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] startup sequencing issue with php_admin_value disable_functions?
At 09:30 24-10-01, Rasmus Lerdorf wrote: At 07:55 24-10-01, Rasmus Lerdorf wrote: php_admin_value disable_functions does not work. Works fine from php.ini. It's not supposed to work, it can only work from php.ini. Why? Look at the code... It's really designed to be a one-time thing, rather than something that can be easily turned on/off - if it was supported on a per-virtual-host basis. It can be implemented, but it would require quite a bit of coding, as this functionality is simply not there right now. -- PHP Development Mailing List http://www.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] Current CVS + Apache2 on Linux
At 13:09 24-10-01, Sebastian Bergmann wrote: dl.c: In function `zif_dl': dl.c:79: structure has no member named `full_tables_cleanup' You didn't update your Zend dir... -- PHP Development Mailing List http://www.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] phpinfo() : Why no PHP Zend image when expose_php=off?
Yes, it's quite intentional.
Because there is no way to embed images within HTML, the way PHP displays
these images is by detecting a special kind of input string. If this input
string is detected, PHP spits out the PHP or Zend image, as
necessary. Since this allows remote users to detect whether PHP is
installed, this feature is disabled when you have expose_php set to off.
At 15:09 24-10-01, Yasuo Ohgaki wrote:
I'm curious about why there is no PHP Zend image and take a look
at info.c finally.
phpinfo() do not show PHP Zend logo when expose_php is set to
off. I thought this is a some thought of a problem at first. This
behaviour is confusing anyway. Any good reason for this?
It just doesn't make sense, no images if expose_php=off.
Any need to hide images, if expose_php=off?
Here is code from ext/standard/info.c.
-
if (expose_php) {
PUTS(a href=\http://www.php.net/\;img src=\);
if (SG(request_info).request_uri) {
PUTS(SG(request_info).request_uri);
}
if ((ta-tm_mon==3) (ta-tm_mday==1)) {
PUTS(?=PHP_EGG_LOGO_GUID\ border=0 align=\right\
alt=\Thies!\/a);
} else {
PUTS(?=PHP_LOGO_GUID\ border=0 align=\right\ alt=\PHP
Logo\/a);
}
}
-
php_info_print_box_start(0);
if (expose_php) {
PUTS(a href=\http://www.zend.com/\;img src=\);
if (SG(request_info).request_uri) {
PUTS(SG(request_info).request_uri);
}
PUTS(?=ZEND_LOGO_GUID\ border=\0\ align=\right\ alt=\Zend
logo\/a\n);
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.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] startup sequencing issue with php_admin_value disable_functions?
At 17:44 24-10-01, Rasmus Lerdorf wrote: At 09:30 24-10-01, Rasmus Lerdorf wrote: At 07:55 24-10-01, Rasmus Lerdorf wrote: php_admin_value disable_functions does not work. Works fine from php.ini. It's not supposed to work, it can only work from php.ini. Why? Look at the code... It's really designed to be a one-time thing, rather than something that can be easily turned on/off - if it was supported on a per-virtual-host basis. It can be implemented, but it would require quite a bit of coding, as this functionality is simply not there right now. I did look at the code and I still don't understand. It's not like httpd.conf directives can be run multiple times under normal circumstances. Yes they can. The way PHP works is that you have different settings for different vhosts, or different directories for that matter, each request will first set PHP up to the right settings, and then perform the request... There aren't copies of the data structures (e.g., the function table) for different vhosts. If we were to make it work, we'd have to implement a mechanism that knows how to disable functions and re-enable them when the request terminates, so that the next request is not affected. It's not impossible, but this code currently does not exist. 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] Memory consumption / usage
Try Thies's thing first. It may not be PHP memory at all, but (a) Memory fragmentation (much tougher to handle, but we need to know what we're up against) (b) Non PHP memory Thies's memory reporting will help you determine whether it's really PHP that's taking so much memory. If it is, we can look further... At 12:36 25-10-01, Ulf Wendel wrote: Joerg Behrens wrote: is there a way to monitor the memory usage of a php script and especially the size of it's variables? Thies added a patch long time ago to log the memory usage of a php script into the apache log files. Well, I'm using a set of scripts to monitor the systemload and the size of http processes. I knew that there's such a Thies (?) but it's not exactly what I would like to know. I'm more intrested in some kind of dump_sizeof($GLOBALS). Ulf -- NetUSE AG Dr.-Hell-Straße Fon: +49 431 386 436 00 http://www.netuse.de/ D-24107 Kiel Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.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] command-line debugging broken?
Look up in the archives... Basically if there are any leaks in emalloc()'d data that was loaded in a dynamic module, memory blocks will be pointing at addresses which no longer exist if we're in debug mode (the __FILE__ stuff). Zeev At 00:58 26/10/2001, Markus Fischer wrote: On Thu, Oct 25, 2001 at 06:50:10PM +0200, Andi Gutmans wrote : dl() is evil! This is a bug which most likely will never be resolved (except for nuking dl()). Can you elaborate more? Technically? - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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] dl() equivalent
In my opinion, not really - it'll just replace one mess with another... At 08:43 27/10/2001, Stig S. Bakken wrote: Hi, Back in the early 3.0 days, dl() used to load stuff into the process without removing it at the end of the request. Zeev, would not yanking modules back out at request shutdown eliminate some of the evilness of dl()? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #13847 Updated: php hangs after newest ie6 critical update
Can anybody else confirm this? At 17:38 27/10/2001, John Lim wrote: I suggest you run PHP as a CGI as a workaround. [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... ID: 13847 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *General Issues Operating System: Windows 2000 PHP Version: 4.0.6 New Comment: Report this to Microsoft. Not PHP bug. Previous Comments: [2001-10-27 05:45:52] [EMAIL PROTECTED] Dear php team, After I installed an ie6 newest critical update, pages with php extension will hang iis. After I remove php from isapi filter, iis works fine! The error message is as follow: inetinfo.exe - Application Error The instruction at 0x016d18e0 referenced memory at 0x016d18e0. The memory could not be read. My whole site becomes not workable. There is no way in uninstall ie6 except re-install 2000 everything. Help please. Edit this bug report at http://bugs.php.net/?id=13847edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Echo vs in/out
As a matter of fact, going into and out of HTML blocks generates pretty
much the same intermediate code as echo does - echo is built into the
language at the very same level. If you use printf() or something like
that, though, you'll feel a significant difference.
That wasn't the case in PHP 3.0 (as far as I recall anyway, it's been a
while).
Zeev
On Sun, 28 Oct 2001, Brian Moon wrote:
It has always been my understanding that in/out is faster as PHP does not
have to evalutate the terms for variables. The best test would be to use an
app like apache bench (aka: ab) against the two pages. Like this:
Test 1
---
?php
$var=array(1,2,3,4,5);
for($x=0;$x100;$x++){
echo Hello;
}
$var2=array(6,7,8,9,10);
?
results:
-
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Apache/1.3.20
Server Hostname:phorum.org
Server Port:80
Document Path: /~brian/test.php
Document Length:500 bytes
Concurrency Level: 3
Time taken for tests: 0.523 seconds
Complete requests: 100
Failed requests:0
Total transferred: 67830 bytes
HTML transferred: 51000 bytes
Requests per second:191.20
Transfer rate: 129.69 kb/s received
Connnection Times (ms)
min avg max
Connect:1 4 8
Processing:12 9 7
Total: 131315
Test 2
---
?php
$var=array(1,2,3,4,5);
for($x=0;$x100;$x++){
?Hello?php
}
$var2=array(6,7,8,9,10);
?
results:
-
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Apache/1.3.20
Server Hostname:phorum.org
Server Port:80
Document Path: /~brian/test1.php
Document Length:500 bytes
Concurrency Level: 3
Time taken for tests: 0.515 seconds
Complete requests: 100
Failed requests:0
Total transferred: 67830 bytes
HTML transferred: 51000 bytes
Requests per second:194.17
Transfer rate: 131.71 kb/s received
Connnection Times (ms)
min avg max
Connect:1 4 8
Processing:11 9 7
Total: 121315
---
So, as you can see, there is a difference but not that much. Perhaps if you
were echoing an entire page it would make a large difference. You should
read Nathan Wallace's paper PHP: Hackers Paradise Revisited
http://www.e-gineer.com/articles/php-hackers-paradise-revisited.phtml. In
it he talks about speed of coding and not speed of code. Take it with a
grain of salt but it is true. Sometimes it is more important how long it
takes to code something than it is how fast it runs. PHP makes it easy to
code fast while making sure the code runs fast enough.
Brian.
- Original Message -
From: Andre Næss [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 6:11 PM
Subject: [PHP-DEV] Echo vs in/out
I'm currently in the middle of a discussion with some fellow PHP
developers regarding the speed of what we call in/out compared to
echo. With in/out we mean stuff like this:
// php code
?
htmlsome html/html
?php
// more php
The manual states that PHP treats ??php as an echo statement, and I
don't think there can be any speed difference between the two, however one
of my fellow developers thinks there is a difference, and created a test
which showed a 60% speed difference (using a for loop that ran 1
times). The test was badly executed IMO, so I ran my own which showed
virtually no difference, but rather than getting into a flame-war I
thought I'd just ask here for a quick answer. Is there a difference, and
if so, is it significant?
Regards
André Næss
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] $class::bar() yields parse error
At 11:33 29/10/2001, Sebastian Bergmann wrote:
Calling static methods on 'variable' classes currently yields a parse
error:
?php
class foo {
function bar() {
echo 'foobar';
}
}
$class = 'foo';
$class::bar();
?
I think it would be great if the above syntax would be possible. Any
technical obstacles, comments?
Yes, currently this has to be resolved in compile time. This may (probably
will) change in the Engine 2.0.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] URL fopen wrappers issue
Can someone familiar with the code confirm that the conditional initialization of the fopen wrappers in basic_functions.c is bogus, and that it should be initialized even if fopen wrappers are turned off at the startup stage? 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] php_ini.c.diff
Can you commit it?
At 01:40 31/10/2001, Yasuo Ohgaki wrote:
This patch fixes small phpinfo() problem.
Current phpinfo() does not display values properly, if
- value is string AND
- value is not set in php.ini AND
- value is modified by other places such as .htaccess,
httpd.conf, etc.
(It supposed to print no value, but it doesn't. With mozilla,
orig_value cell is rendered as black box.)
--
Yasuo Ohgaki
Index: php_ini.c
=== RCS
file: /repository/php4/main/php_ini.c,v retrieving revision 1.74 diff -u
-r1.74 php_ini.c --- php_ini.c6 Oct 2001 20:13:38 - 1.74
+++ php_ini.c 30 Oct 2001 08:34:31 - @@ -50,7 +50,7
@@uint display_string_length, esc_html=0; if
(type==ZEND_INI_DISPLAY_ORIG ini_entry-modified) {
- if (ini_entry-orig_value) { + if
(ini_entry-orig_value ini_entry-orig_value[0])
{display_string =
ini_entry-orig_value;
display_string_length =
ini_entry-orig_value_length; esc_html=1--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] php_ini.c.diff
Submit a request - and you'd be approved :) At 12:52 01/11/2001, Yasuo Ohgaki wrote: Zeev Suraski wrote: Can you commit it? I'm afraid not, since I don't have CVS account. If anyone could give me a CVS account, I might be able to contribute a little for QA Team, Japanese Documentation and a little bugfix or coding for modules. I need asnycronous query interface (pgsql) for better performance. If anyone is not interested in writing the interface, I might write it. -- Yasuo Ohgaki At 01:40 31/10/2001, Yasuo Ohgaki wrote: This patch fixes small phpinfo() problem. Current phpinfo() does not display values properly, if - value is string AND - value is not set in php.ini AND - value is modified by other places such as .htaccess, httpd.conf, etc. (It supposed to print no value, but it doesn't. With mozilla, orig_value cell is rendered as black box.) -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Benjamin Kromann
Congratulations! At 12:56 01/11/2001, Frank M. Kromann wrote: Hi, It is getting late now in CA, but I have to tell you all about Benjamin Kromann, our new son :-) He was born last night at 11:23pm and he is a healthy boy 50 cm long and he weighs 3550 g. Mis mom is doing very well allthough we all need some sleep now. Happy hacking to all of you and I'll be back in a couple of weeks. - Frank -- PHP Development Mailing List http://www.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] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
Guys, I mentioned this in the conference. Version numbers aren't going to change anything significant. If we're concerned about the users' perception of what the version number means, moving to Jani's versioning scheme, I'm pretty confident it'll mean less to more people. The reason being the fact that people are used to PHP's existing versioning scheme, which is the de-facto standard in the opensource world, and you should be quite aware that the vast majority of users will never read our explanation as to what the version number means, no matter how nicely we put it. That's the advantage of using a standard. I think that we're too harsh on the system we have in place right now. It usually works. It really does. True, 4.0.7 lingered on for a variety of good and bad reasons, but even in this extreme case - we're not faced with a tragedy, but some dilemma, at most. *Every* system has its advantages and its disadvantages, there's no perfect system. Those who suggest that we switch should think carefully about what the gains will be, and whether they'll be worth the losses. I have a feeling that currently people feel that 'anything would be better than what we have now', when in reality, we have a system that works at say 70% or 80% efficiency, and switching may very well make things worse at the bottom line (i.e., worse product for the end user) than they are today. Zeev At 01:31 11/11/2001, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13806 Updated: zlib compression is not broken, but other code breaks it?
At 03:44 11/11/2001, [EMAIL PROTECTED] wrote: result - 4.1.0RC: 4.1.0RC works fine without zlib compression, but not with zlib output compression. httpd just keeps growing when output exceed buf size. (I killed it when it became 100MB) It cannot display phpinfo(). There are many log entry for memory leak for apache. result - 4.2.0: It seems there is no problem in 4.2.0 now. It works for both script and can display phpinfo(). (It was not working before, at least when 4.1.0RC1 is released.) output.c has not been changed. It seems real problem was in some other place. What do you mean by output.c not being changed? 4.1.0RC1 and HEAD have different output.c's... Can you try to apply the patches at http://cvs.php.net/diff.php/php4/main/output.c?ws=0r1=1.75r2=1.77ty=u to 4.1.0RC1, and see if the problem goes away? It should apply cleanly, except for a meaningless $Id conflict. The 4.0.7 codebase did not support multiple layers of internal/chunked output buffering, so mixing output buffering and mbstring-auto-encoding did not work. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13806 Updated: zlib compression is not
At 10:47 11/11/2001, Yasuo Ohgaki wrote: Can you try to apply the patches at http://cvs.php.net/diff.php/php4/main/output.c?ws=0r1=1.75r2=1.77ty=u to 4.1.0RC1, and see if the problem goes away? It should apply cleanly, except for a meaningless $Id conflict. I tried and it *works*. Now 4.1.0RC CVS works really well so far, but more tests are needed. Ok, great. I'll import the patch to the 4.1.0 branch then. 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] Re: Wow ! Good news (to me at least) ...
I promised that anybody that I'll break the neck of anybody that complains about not going with the GPL. Please inform me of any PHP conferences you intend to attend, so I know where to find you :) Zeev At 20:28 08/11/2001, August Zajonc wrote: Why not the GPL? But excellent any which way... L0t3k [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... http://zend.com/news/pr.php?id=26 -- PHP Development Mailing List http://www.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= ? sytanx again
SHORT TAGS WILL NOT BE DEPRECATED.
There.
Zeev
At 15:54 09/11/2001, Jani Taskinen wrote:
It's not only because of xml stuff but also because of
the portability reasons..not everyone has short-tags enabled.
Would it be that most of the people who have them enabled do that
just because ?php= doesn't work..?
+1 for ?php= if those short-tags are deprecated. :)
--Jani
On Fri, 9 Nov 2001, Edin Kadribasic wrote:
Combine that with incompatibility of PHP's short open tag with XML, and
the
reason for having ?php= becomes clearer.
As Rasmus is probably tired of pointing out, this isn't much of an
argument.
This:
if ($i 4) {
...
is incompatible with XML (it'd have to be if ($i lt; 4) ...)
That's not what I'm talking about. Last time I tried
?xml ...
with short open tag enabled, PHP gave me parse error.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Wow ! Good news (to me at least) ...
At 22:04 09/11/2001, Sebastian Bergmann wrote: Zeev Suraski wrote: I promised that anybody that I'll break the neck of anybody that complains about not going with the GPL. Please inform me of any PHP conferences you intend to attend, so I know where to find you :) Any guess on when a decision for the final license is reached? No, not really. Well, actually, if I was to guess - I could guess/hope it won't take more than two weeks or so. I'm going to talk to Andi on Sunday and we'll pitch something, probably similar/identical to that of the PHP license, and see how it goes from there. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.1.0
Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. There are basically two options: (a) Go with 4.1.0 based on 4.0.7 the way we originally intended. Pros: It's pretty stable, tested, and pretty much ready to go out the door with minimum extra work. Cons: We get a release out there that is based on code from several months ago, which doesn't contain some bug fixes and changes. (b) Drop the current release branch. Rebranch from HEAD, and release 4.1.0 based on the current CVS. Pros: All of the bug fixes/features go into 4.1.0, we don't release a version based on old code. Cons: Requires a complete new cycle of QA, as lots of key issues changed since we branched. Two major examples that come to mind are the sessions code (trans_sid) and file uploads, which were very significantly changed. My personal opinion is that we should go on with (a), and start the release process for 4.2.0, based on the latest CVS, immediately afterwards. I fear instability in the new sessions/file upload code too much, and don't want to delay 4.1.0 for much longer. Thies, on the other hand, supports option (b), because he's afraid of having a new release based on several months old CVS is going to be a headache. Your comments are quite welcome, let's try to reach consensus as soon as we can (wishful thinking? :) 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] 4.1.0
At 17:43 10/11/2001, Rasmus Lerdorf wrote: I think the assumption that the PHP_4_0_7 branch is pretty stable and pretty much ready to go is the key here. How do you know? I think it is up to the QA team to tell us if this is the case. From what I can see, I don't think this is so. From looking at the QA list, the reports for 4.0.7 were pretty good. Nobody complained about anything out of the ordinary, except for this zlib compression issue, which may be authentic, or may be a true out-of-memory situation. At any rate, considering the fact it's a new feature, it's shouldn't be a show stopper anyway. Based on a long 4.0.7 testing and a short 4.1.0 testing, I'd say 4.1.0 would be of the same quality as 4.0.6, with more bug fixes and some key new features that people need to start building upon. These features (namely, the new secure $_GET, $_POST and friends) should not be delayed for an unknown amount of time, which will take us to stabilize HEAD. 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] 4.1.0
Rasmus - whatever that issue is, it has not been fixed in HEAD. Zeev At 17:43 10/11/2001, Rasmus Lerdorf wrote: I think the assumption that the PHP_4_0_7 branch is pretty stable and pretty much ready to go is the key here. How do you know? I think it is up to the QA team to tell us if this is the case. From what I can see, I don't think this is so. Jani, did you ever resolve that issue you posted about on Oct.24 related to bug #13806? You said it was only reproducable in the branch but fine in HEAD at the time. -Rasmus On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. There are basically two options: (a) Go with 4.1.0 based on 4.0.7 the way we originally intended. Pros: It's pretty stable, tested, and pretty much ready to go out the door with minimum extra work. Cons: We get a release out there that is based on code from several months ago, which doesn't contain some bug fixes and changes. (b) Drop the current release branch. Rebranch from HEAD, and release 4.1.0 based on the current CVS. Pros: All of the bug fixes/features go into 4.1.0, we don't release a version based on old code. Cons: Requires a complete new cycle of QA, as lots of key issues changed since we branched. Two major examples that come to mind are the sessions code (trans_sid) and file uploads, which were very significantly changed. My personal opinion is that we should go on with (a), and start the release process for 4.2.0, based on the latest CVS, immediately afterwards. I fear instability in the new sessions/file upload code too much, and don't want to delay 4.1.0 for much longer. Thies, on the other hand, supports option (b), because he's afraid of having a new release based on several months old CVS is going to be a headache. Your comments are quite welcome, let's try to reach consensus as soon as we can (wishful thinking? :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Memory issue with output compression (was Re: [PHP-DEV] 4.1.0)
After some more investigation, it *might* be related to a bug that existed in 4.0.7 with multiple levels of internal output buffering, so I may have spoken too soon. I can't really reproduce it, so I asked Yasuo Ohgaki to take a look at it. If it's indeed the issue, it's a one line fix that can be MFH'd today, and at any rate, it'll only affect people who use zlib.output_compression, plus the mbstring automatic conversion feature. Another option is that it may be a bug in the mbstring auto conversion, as there's at least one more bug report that may be related (#13698). It crashes under both HEAD and 4.1.0RC1 (HEAD requires a more complex script, but the bug is there). Zeev At 16:57 10/11/2001, Zeev Suraski wrote: Rasmus - whatever that issue is, it has not been fixed in HEAD. Zeev At 17:43 10/11/2001, Rasmus Lerdorf wrote: I think the assumption that the PHP_4_0_7 branch is pretty stable and pretty much ready to go is the key here. How do you know? I think it is up to the QA team to tell us if this is the case. From what I can see, I don't think this is so. Jani, did you ever resolve that issue you posted about on Oct.24 related to bug #13806? You said it was only reproducable in the branch but fine in HEAD at the time. -Rasmus On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. There are basically two options: (a) Go with 4.1.0 based on 4.0.7 the way we originally intended. Pros: It's pretty stable, tested, and pretty much ready to go out the door with minimum extra work. Cons: We get a release out there that is based on code from several months ago, which doesn't contain some bug fixes and changes. (b) Drop the current release branch. Rebranch from HEAD, and release 4.1.0 based on the current CVS. Pros: All of the bug fixes/features go into 4.1.0, we don't release a version based on old code. Cons: Requires a complete new cycle of QA, as lots of key issues changed since we branched. Two major examples that come to mind are the sessions code (trans_sid) and file uploads, which were very significantly changed. My personal opinion is that we should go on with (a), and start the release process for 4.2.0, based on the latest CVS, immediately afterwards. I fear instability in the new sessions/file upload code too much, and don't want to delay 4.1.0 for much longer. Thies, on the other hand, supports option (b), because he's afraid of having a new release based on several months old CVS is going to be a headache. Your comments are quite welcome, let's try to reach consensus as soon as we can (wishful thinking? :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 05:28 12/11/2001, Jani Taskinen wrote: Zeev suggested at some point that we should drop the last number altogether. I *what*? Perhaps I was high on that Kossu :) I was never in favour of dropping the 3rd digit. That indeed would make the current way of doing things more correct but would not really solve anything in the user end.. Indeed. What I suggested: Only bug fixes go into the release branch. And all the nifty new features and big changes and BC breaking stuff go into the next release branch (HEAD). (ie. version 4.x+1.0 ) As I've said repeatedly, there's no reason *at all* to move from our old, de-facto standard versioning scheme to this one. The process is fine, but the following version should be a .0.1 add-up. I really fail to see why you mix the version number with what a new version may include. And, of course, it has nothing to do with the fact that once we branch a release branch, be it 4.0.7 or 6.4.2.4.6.1.2.5.4, no new features should go to it - only bug fixes. It's not very far from what we are doing right now. We have two branches, the release one and HEAD. But what I suggested was to keep the release branch and commit bug fixes into it and release bug-fix-only-releases from it. Why would it be hard time doing it? It's not hard as long as certain rules are followed. It needs a bit more work and people who are dedicated for doing it. But the core developers ([EMAIL PROTECTED]) should first ratify all this stuff. :) Jani, it's simply not going to work. New features and bug fixes are often closely interweaved. Also, *bugs* and new features are often closely interweaved. What you are suggesting is basically to step with full steam into the biggest synchronization nightmare possible. The system and rules we have right now are good. The flaw, if any, is in the amount of work that goes into bug fixing, from your point of view, which I can certainly understand. But changing the system to what you propose will not improve things - only more efforts towards bug fixing will. Not only that - it's bound to create synchronization problems from hell, things you don't even dream about when you use a simple linear development model as we do today. It has nothing to do with whether or not php-dev can live up to certain rules, or whether it should or shouldn't do so. Rules are not the problem here. 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] 4.1.0
The one symptom Rasmus pointed out (which was quite specific for mbstring-xlation+zlib-compression) was MFH'd, so I think there are no big showstoppers left. Zeev At 20:55 12/11/2001, Andrei Zmievski wrote: On Mon, 12 Nov 2001, James Moore wrote: Putting out a release we arnt happy with is worse than not putting a release out at all. Just wondering what in the current branch people aren't happy with. -Andrei * http://www.zend.com/comm_person.php?id=24 * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1.0
I suggest an RC2 (today?) and a release by the end of the week, or Monday at the latest. James - how sure are you that the fix you submitted is good and that we won't find out afterwards that the bogus behavior was actually the right thing to do? :) Zeev At 21:14 12/11/2001, Andrei Zmievski wrote: On Mon, 12 Nov 2001, Zeev Suraski wrote: The one symptom Rasmus pointed out (which was quite specific for mbstring-xlation+zlib-compression) was MFH'd, so I think there are no big showstoppers left. I'm ++1 for releasing current branch ASAP. -Andrei The main reason Santa is so jolly is because he knows where all the bad girls live. -- George Carlin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1.0
Code doesn't grow old. There's really no reason not to release 4.1.0, and start the 4.2.0 releasing immediately afterwards. Mixing the fact we're stressed to put out a released (due to the $_GETfriends feature) and the fact that we have several big changes in key features (sessions, file uploads) is a 'clear and present danger', in my opinion. We should be able to take our time with it, if necessary. Zeev At 20:54 12/11/2001, James Moore wrote: i haven't really changed my mind - but i want a fast decision. as there isn't any clear consens here i think we should release 4.1 as-it-is-with-the-last-showstoppers-fixed and go from there. we should also learn from this and assign a RM for the next release! i mean a real release-master... Putting out a release we arnt happy with is worse than not putting a release out at all. Lets restart the cycle and take care this time.. 4.1.x is asking for trouble coming from a branch as old as the 4_0_7 branch is..lets rebranch from HEAD and really push the release we could probably get it out in 1.5 - 2 weeks. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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.1.0RC2 - can we roll?
I'm going to roll PHP 4.1.0RC2 in an hour if nobody shouts. 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] Re: PHP 4.1.0RC2 - can we roll?
The version in the branch has no curl_global_init() call at all. I'm assuming it's ok to add it - Sterling - please shout if it isn't :) Zeev At 03:08 13/11/2001, James Moore wrote: - Original Message - From: Alan Knowles [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 12:31 AM Subject: Re: [PHP-DEV] Re: PHP 4.1.0RC2 - can we roll? This may sound a bit self interested, but the curl extension has a serious (well to me :) bug that prevents https working - If somebody wants to patch/test this - it would be one less bug in 4.1.0RC2 :) -- I have done quite a but if testing here - (with and without openssl libraries) This was due to an api change in libcurl in May - so I think most people would have updated their libraries by now. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/curl/curl/lib/easy.c.diff?r1= 1.15r2=1.16 Bug report with tested patch at http://bugs.php.net/bug.php?id=14023 Zeev is commiting merging this into the release branch now, Ill give it a good testing on win32 tomorrow... - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.1.0RC2
http://www.php.net/~zeev/php-4.1.0RC2.tar.gz Do your thang :) 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] To Merge, Or Not To Merge?
I don't think we want any more RC's unless there's some real pressing matter, and that doesn't appear to qualify :) At 07:51 13/11/2001, Sebastian Bergmann wrote: Should we merge the recent changes to sapi/servlet to the 4_0_7 branch, or not? The changes are required in order to use the Servlet SAPI module with current versions of Tomcat and Cocoon2. It is not stable, though, as I discussed with Zeev at the Conference... -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1.0RC2
Either that or we can simply check if this #define exists... What do you think? Zeev At 11:37 13/11/2001, Balazs Nagy wrote: On Tue, Nov 13 2001, Zeev Suraski [EMAIL PROTECTED] wrote: http://www.php.net/~zeev/php-4.1.0RC2.tar.gz Do your thang :) make[1]: Entering directory /home/js/dl/linux/web/php-4.1.0RC2/ext/curl' gcc -I. -I/home/js/dl/linux/web/php-4.1.0RC2/ext/curl -I/home/js/dl/linux/web/php-4.1.0RC2/main -I/home/js/dl/linux/web/php-4.1.0RC2 -I/home/js/dl/linux/web/php-4.1.0RC2/Zend -I/usr/include/freetype2/freetype -I/home/js/dl/linux/web/php-4.1.0RC2/ext/xml/expat -I/home/js/dl/linux/web/php-4.1.0RC2/TSRM -g -Wall -c curl.c touch curl.lo curl.c: In function `zm_startup_curl': curl.c:145: `CURLOPT_SSL_VERIFYHOST' undeclared (first use in this function) curl.c:145: (Each undeclared identifier is reported only once curl.c:145: for each function it appears in.) curl.c: In function `zif_curl_setopt': curl.c:640: `CURLOPT_SSL_VERIFYHOST' undeclared (first use in this function) make[1]: *** [curl.lo] Error 1 make[1]: Leaving directory /home/js/dl/linux/web/php-4.1.0RC2/ext/curl' make: *** [all-recursive] Error 1 It doesn't work with curl-7.8. It's old enough but this version is included into Red Hat Linux 7.2. In the 7.9.1 CHANGES file: Version 7.8.1-pre4 [...] - Patrick Bihan-Faou introduced CURLOPT_SSL_VERIFYHOST, which makes curl verify the server's CN field when talking https://. If --cacert is not used, any failures in matching is only displayed as information (-v). Thus configure's curl check should contain a version check for 7.8.1 or higher. -- jul -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1.0RC2
It's quite different actually - if we conduct a configure test, then presumably we'll refuse to compile under CURL below version 3.8.1 or whatever version it is. If we do an #ifdef check, it'll work with older CURL's. Zeev At 11:56 13/11/2001, Balazs Nagy wrote: On Tue, Nov 13 2001, Zeev Suraski [EMAIL PROTECTED] wrote: Either that or we can simply check if this #define exists... What do you think? Checking for a version and for a #define is the same, but version checking is more subtle and can be hidden than another check for the #define's existence. -- jul -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
I think we should be realistic about what we can and cannot pull. Using this approach as the standard release process is simply not going to work - we barely manage an RC branch and a dev branch properly, and having to maintain an old release branch sync'd with bug fixes is not going to be within our reach. In very specific cases, such as the 4.1.0 - 4.2.0 change, if there are going to be some key bugs in 4.1.0, releasing a 4.1.1 based on 4.1.0 would be in order. Otherwise, though, I would say that we're only toying with a non practical idea :) Zeev At 02:36 14/11/2001, Stig S. Bakken wrote: Andi Gutmans wrote: At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). - Stig -- PHP Quality Assurance Mailing List http://www.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] Re: Bugs pending for PHP 4.1.0
At 10:08 16/11/2001, Derick Rethans wrote: Hello, here is my list of important pending bugs which need to be fixed before PHP 4.1.0 can be released IMO. -- Bug 11813 (not really a bug): [ImageGammaCorrect no longer works] Let's keep this open (critical) until it really is solved. And I think there should be two modules in the win32 release, for both 1.8.x and 2.0.x versions of GD. I don't think that should be a showstopper of any kind..? -- Bug 13143 (patch attached): [TSRM fails to build] GCC 2 ignores it, GCC 3 does not. I applied the patch... -- Bug 13703: [PHP allows function redefinition] Something weird going on with multiple function definitions in classes In the hope that we actually release 4.1.0 in this millennium, I think that should also stay unsolved for now. I wouldn't want to touch this part without another RC, and I hope we won't have another RC. This was most probably the behavior since at least 4.0.0, and it's not a crash bug, so I think it can wait for a later version... -- Bug 13711: [set_time_limit affects other requests on the same Apache process] Trying to reproduce this now. Pretty much by definition this cannot happen. We'd have to go through hoops to create this behavior under Linux. Under Windows, there may be a bug that breaks the multithreaded alarm system, and I'll check it out, but for the same reasons above, I don't think it should stale 4.1.0. -- Bug 14014: [Need later config.guess/config.sub] Can someone look at bug#14014 before we do 4.1.0 (or what ever the next release is?) It breaks being able to build on OpenUNIX 8. If somebody gets to look at it - great. Please do it ASAP, as I want to go with 4.1.0 final early next week. If worse comes to worse, we won't have OpenUNIX 8 support in 4.1.0... 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] set_time_limit() bug - pending for PHP 4.1.0
Uhm, what exactly did you reproduce?
Zeev
At 02:19 PM 11/18/2001, Derick Rethans wrote:
On Sun, 18 Nov 2001, Sander Roobol wrote:
I created two scripts.
?php set_time_limit(1); ?
?php
for($i=0; $i100; $i++) {
base64_encode(md5($i));
}
?
Reproducing this bug on Linux is hard. On Windows, it's very easy. On
Linux,
you should repeatedly load both the first and the second script.
Reproducing under Linux was very easy for me, I just set the following
things in httpd.conf:
MinSpareServers 1
MaxSpareServers 1
StartServers 1
And voila, reproduced. SO this is a real problem, and need to be addressed
before release.
I used the CVS of last night, following configure line:
./configure \
--with-apache=/dat/dev/php/$APACHE_DIR \
--with-gd \
--with-ttf --with-mysql --with-pdflib=/usr/local \
--enable-pdflib --with-config-file-path=/etc/httpd \
--enable-track-vars --enable-magiq-quotes --enable-memory-limit \
--enable-ftp --with-srm=/opt/srm --with-mcrypt \
--with-ctype --with-gmp --with-ldap \
--with-ncurses \
--enable-shmop --enable-sockets --enable-sysvsem \
--enable-sysvshm --enable-wddx --with-zlib
(and yes, I know that magic-quotes does not work :)
regards,
Derick
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.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] set_time_limit() bug - pending for PHP 4.1.0
Ah, well, the bug was discussing something else (I think). I'll look into it.
Zeev
At 02:50 PM 11/18/2001, [EMAIL PROTECTED] wrote:
On Sun, 18 Nov 2001, Zeev Suraski wrote:
Uhm, what exactly did you reproduce?
That set_time_limit() affects the whole apache child, and not only the
current script.
Derick
Zeev
At 02:19 PM 11/18/2001, Derick Rethans wrote:
On Sun, 18 Nov 2001, Sander Roobol wrote:
I created two scripts.
?php set_time_limit(1); ?
?php
for($i=0; $i100; $i++) {
base64_encode(md5($i));
}
?
Reproducing this bug on Linux is hard. On Windows, it's very easy. On
Linux,
you should repeatedly load both the first and the second script.
Reproducing under Linux was very easy for me, I just set the following
things in httpd.conf:
MinSpareServers 1
MaxSpareServers 1
StartServers 1
And voila, reproduced. SO this is a real problem, and need to be addressed
before release.
I used the CVS of last night, following configure line:
./configure \
--with-apache=/dat/dev/php/$APACHE_DIR \
--with-gd \
--with-ttf --with-mysql --with-pdflib=/usr/local \
--enable-pdflib --with-config-file-path=/etc/httpd \
--enable-track-vars --enable-magiq-quotes --enable-memory-limit \
--enable-ftp --with-srm=/opt/srm --with-mcrypt \
--with-ctype --with-gmp --with-ldap \
--with-ncurses \
--enable-shmop --enable-sockets --enable-sysvsem \
--enable-sysvshm --enable-wddx --with-zlib
(and yes, I know that magic-quotes does not work :)
regards,
Derick
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.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] set_time_limit() bug - pending for PHP 4.1.0
Looks like I misread the bug, I'll look into it.
At 03:11 PM 11/18/2001, Zeev Suraski wrote:
Ah, well, the bug was discussing something else (I think). I'll look into it.
Zeev
At 02:50 PM 11/18/2001, [EMAIL PROTECTED] wrote:
On Sun, 18 Nov 2001, Zeev Suraski wrote:
Uhm, what exactly did you reproduce?
That set_time_limit() affects the whole apache child, and not only the
current script.
Derick
Zeev
At 02:19 PM 11/18/2001, Derick Rethans wrote:
On Sun, 18 Nov 2001, Sander Roobol wrote:
I created two scripts.
?php set_time_limit(1); ?
?php
for($i=0; $i100; $i++) {
base64_encode(md5($i));
}
?
Reproducing this bug on Linux is hard. On Windows, it's very easy. On
Linux,
you should repeatedly load both the first and the second script.
Reproducing under Linux was very easy for me, I just set the following
things in httpd.conf:
MinSpareServers 1
MaxSpareServers 1
StartServers 1
And voila, reproduced. SO this is a real problem, and need to be
addressed
before release.
I used the CVS of last night, following configure line:
./configure \
--with-apache=/dat/dev/php/$APACHE_DIR \
--with-gd \
--with-ttf --with-mysql --with-pdflib=/usr/local \
--enable-pdflib --with-config-file-path=/etc/httpd \
--enable-track-vars --enable-magiq-quotes --enable-memory-limit \
--enable-ftp --with-srm=/opt/srm --with-mcrypt \
--with-ctype --with-gmp --with-ldap \
--with-ncurses \
--enable-shmop --enable-sockets --enable-sysvsem \
--enable-sysvshm --enable-wddx --with-zlib
(and yes, I know that magic-quotes does not work :)
regards,
Derick
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] set_time_limit() bug - pending for PHP 4.1.0
Can you describe the exact steps you made in order to reproduce it? It
appears to be working fine on my box.
Zeev
At 02:50 PM 11/18/2001, [EMAIL PROTECTED] wrote:
On Sun, 18 Nov 2001, Zeev Suraski wrote:
Uhm, what exactly did you reproduce?
That set_time_limit() affects the whole apache child, and not only the
current script.
Derick
Zeev
At 02:19 PM 11/18/2001, Derick Rethans wrote:
On Sun, 18 Nov 2001, Sander Roobol wrote:
I created two scripts.
?php set_time_limit(1); ?
?php
for($i=0; $i100; $i++) {
base64_encode(md5($i));
}
?
Reproducing this bug on Linux is hard. On Windows, it's very easy. On
Linux,
you should repeatedly load both the first and the second script.
Reproducing under Linux was very easy for me, I just set the following
things in httpd.conf:
MinSpareServers 1
MaxSpareServers 1
StartServers 1
And voila, reproduced. SO this is a real problem, and need to be addressed
before release.
I used the CVS of last night, following configure line:
./configure \
--with-apache=/dat/dev/php/$APACHE_DIR \
--with-gd \
--with-ttf --with-mysql --with-pdflib=/usr/local \
--enable-pdflib --with-config-file-path=/etc/httpd \
--enable-track-vars --enable-magiq-quotes --enable-memory-limit \
--enable-ftp --with-srm=/opt/srm --with-mcrypt \
--with-ctype --with-gmp --with-ldap \
--with-ncurses \
--enable-shmop --enable-sockets --enable-sysvsem \
--enable-sysvshm --enable-wddx --with-zlib
(and yes, I know that magic-quotes does not work :)
regards,
Derick
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.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] set_time_limit() bug - pending for PHP 4.1.0
set_time_limit() just enforces a time limit, it doesn't save anything anywhere. The timeout is then supposed to get the global setting at the beginning of the next request, so I don't yet understand where this issue is coming from... Zeev At 03:01 PM 11/18/2001, James Moore wrote: could this be similar to the engine=on/engine=off thing that we had quite a while ago?? Or is it due to global rather than local settings being overridden in set_time_limit? - 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] set_time_limit() bug - pending for PHP 4.1.0
Works fine for me :I
At 03:42 PM 11/18/2001, [EMAIL PROTECTED] wrote:
Hallo,
put this in httpd.conf:
MinSpaceServers 1
MaxSpareServers 1
StartServers 1
script one:
bug13711a.php:
?php set_time_limit(1); ?
script two:
bug13711b.php:
?php
for($i=0; $i100; $i++) {
base64_encode(md5($i));
}
?
restart HTTPD
load script one
load script two
That's all,
Derick
On Sun, 18 Nov 2001, Zeev Suraski wrote:
Can you describe the exact steps you made in order to reproduce it? It
appears to be working fine on my box.
Zeev
At 02:50 PM 11/18/2001, [EMAIL PROTECTED] wrote:
On Sun, 18 Nov 2001, Zeev Suraski wrote:
Uhm, what exactly did you reproduce?
That set_time_limit() affects the whole apache child, and not only the
current script.
Derick
Zeev
At 02:19 PM 11/18/2001, Derick Rethans wrote:
On Sun, 18 Nov 2001, Sander Roobol wrote:
I created two scripts.
?php set_time_limit(1); ?
?php
for($i=0; $i100; $i++) {
base64_encode(md5($i));
}
?
Reproducing this bug on Linux is hard. On Windows, it's very
easy. On
Linux,
you should repeatedly load both the first and the second script.
Reproducing under Linux was very easy for me, I just set the following
things in httpd.conf:
MinSpareServers 1
MaxSpareServers 1
StartServers 1
And voila, reproduced. SO this is a real problem, and need to be
addressed
before release.
I used the CVS of last night, following configure line:
./configure \
--with-apache=/dat/dev/php/$APACHE_DIR \
--with-gd \
--with-ttf --with-mysql --with-pdflib=/usr/local \
--enable-pdflib --with-config-file-path=/etc/httpd \
--enable-track-vars --enable-magiq-quotes --enable-memory-limit \
--enable-ftp --with-srm=/opt/srm --with-mcrypt \
--with-ctype --with-gmp --with-ldap \
--with-ncurses \
--enable-shmop --enable-sockets --enable-sysvsem \
--enable-sysvshm --enable-wddx --with-zlib
(and yes, I know that magic-quotes does not work :)
regards,
Derick
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI/Apache: Some characters in incomonig variable names are silently changed (fwd)
As soon as php_register_variable() returns, it's ok to free the variable name. The string itself gets duplicated inside the hash. We have to make sure that duplication/freeing only occurs iff (no typo :) it's necessary, so that the general case remains quick. Zeev At 15:58 19/11/2001, Derick Rethans wrote: resending due to no response: Hello list, It's fairly easy to fix this problem, by just estrdupping the keys before passing them on onto php_register_variabele (sapi/apachi/mod_php4.c:253). The problem is however where to free this estrdupped keys again. Can somebody with some deep knowlegde of the SAPI code look in into this? Derick On 7 Nov 2001 [EMAIL PROTECTED] wrote: Previous Comments: [2001-11-07 01:56:30] [EMAIL PROTECTED] I don't think that FAQ solves that problem. Look at the source code of Apache server. There are several tests of the variable force-response-1.0 there. The problem is not that php code variable is $force-response-1_0, that's OK, but the real problem is that apache variable name in r-subprocess_env is changed too. That's side effect and not pleasent. [2001-11-06 16:30:56] [EMAIL PROTECTED] This is mentioned in http://uk.php.net/manual/en/faq.html.php#AEN63677 . Impossible to find if you don't know where to find it. So changing this to a documentation problem. (the issue is that invalid characters in incoming variable names, like dots, are converted to underscores. This happens with any incoming variable name, be it GET, POST, ENV, or whatever.) Changed subject [2001-11-06 16:09:30] [EMAIL PROTECTED] Apache module mod_setenvif sets variables in r-subprocess_env. If variable name contains character ., then mod_php4.c/sapi_apache_register_server_variables() will replace it with _. This breaks internal variables like force-response-1.0 (php changes it to force-response-1_0). Solution: the key in the php_register_variable() call should be a copy of the real key. Edit this bug report at http://bugs.php.net/?id=13961edit=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] Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] Boulevard Heuvelink 102 - 6828 KT Arnhem - 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 Development Mailing List http://www.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] compiled modules VS. code in php
Generally, a perfect C implementation will always be quicker than a PHP implementation, because the scripting engine has its overhead. However, whether or not you write perfect C code is a different question :) Zeev At 16:51 19/11/2001, colin mcdonald wrote: Hi, I apologize in advance if this is not the place to ask. I just figured, I'd get a better answer from this group. Is there a performance increase by compiling your code into php (either dynamic or static) as opposed to writing complex code in php. Note: this bit of code would be used by every request in the application, reads many files and does a lot of string parsing. thanks, colin -- Colin McDonald - [EMAIL PROTECTED] home: http://nexus.carleton.ca/~colin/ public key: http://nexus.carleton.ca/~colin/pubkey.asc fingerprint: http://nexus.carleton.ca/~colin/fingerprint.asc -- PHP Development Mailing List http://www.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] 4.1.0 Final RC
www.php.net/~zeev/php-4.1.0RC3.tar.gz What does 'Final RC' mean? As discussed with php-qa guys (on IRC, you didn't miss a thread), we decided that the current release process is problematic (surprise surprise :). The particular issue we diagnosed this time was that RC branches were changing too much, and because basically each and every change requires a new RC - the release process can linger for quite a while. There are more issues, but this is definitely an issue on its own. So, we decided that there are going to be two stages for RC's: (a) RC a-la what we had until now. It will usually be in the range of weeks. (b) Once we feel enough bugs have been fixed, a final RC is created. For this RC, only *critical show stoppers* are fixed. That is, even bug fixes are not MFH'd unless they're for critical bugs. If a critical show stopper is found, a fix should be merged to the RC branch, and a new Final RC should be released. So, for the developers amongst you - please do not MFH anything before discussing it on php-dev and convincing everyone it really fixes a critical bug. I expect that the QA guys will phrase what I typed up about the 'Final RC' approach into the release process description. I apologize in advance in case it doesn't make sense to you - it may be a stupid idea, but it may just be me being high on this Finnish Kossu :) Cheers, 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] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status
It's definitely in the zip... Any chance you have your explorer set not to show .dll's or something like that? At 21:25 21/11/2001, Alain Samoun wrote: Checked it again: Nope, you must have it in your system from a previous build or you called it another name... A+ Alain On Wed, Nov 21, 2001 at 06:46:20PM -, James Moore wrote: - Original Message - From: Alain Samoun [EMAIL PROTECTED] To: James Moore [EMAIL PROTECTED] Cc: Zak Greant [EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]; Andy Woolley [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 6:39 PM Subject: Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status James: It seems that the php4ts_debug.dll file is missing in your current build. A+ Alain Its shown as there for me. - 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] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status
Yeah, I'm talking about the same zip. Mine has it - 609,040 bytes big. At 22:51 21/11/2001, Alain Samoun wrote: OK: We are talking about the zip from James site called: php-4.1.0RC3-win32.zip 3186 KB 11/21/01 11:05 Sorry but there is no PHP4TS_DEBUG.DLL there and my system doesn't hide dlls (all other dlls are there). A+ Alain On Wed, Nov 21, 2001 at 10:31:44PM +0200, Zeev Suraski wrote: It's definitely in the zip... Any chance you have your explorer set not to show .dll's or something like that? At 21:25 21/11/2001, Alain Samoun wrote: Checked it again: Nope, you must have it in your system from a previous build or you called it another name... A+ Alain On Wed, Nov 21, 2001 at 06:46:20PM -, James Moore wrote: - Original Message - From: Alain Samoun [EMAIL PROTECTED] To: James Moore [EMAIL PROTECTED] Cc: Zak Greant [EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]; Andy Woolley [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 6:39 PM Subject: Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status James: It seems that the php4ts_debug.dll file is missing in your current build. A+ Alain Its shown as there for me. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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] maybe serious error in RC3 memory manager
The chances that it's in the memory manager are very very slim... The memory manager is a poor component - if there's a bug anywhere in PHP, the crash is very likely to appear to point at the memory manager :) Does this script use any fancy modules? Zeev At 17:22 24/11/2001, Stig Venaas wrote: Hi I don't know for sure yet, but wanted to warn you. I'm digging into this, but right now I have a script that runs for a long time after the last line in the script is executed, and then it segfaults with: bFatal error/b: Maximum execution time of 30 seconds exceeded in bUnknown/b on line b0/bbr Program received signal SIGSEGV, Segmentation fault. 0x40124df0 in chunk_free (ar_ptr=0x401cdf00, p=0x15f2e560) at malloc.c:3131 3131malloc.c: No such file or directory. in malloc.c (gdb) bt #0 0x40124df0 in chunk_free (ar_ptr=0x401cdf00, p=0x15f2e560) at malloc.c:3131 #1 0x40124d59 in __libc_free (mem=0x15f2e5a0) at malloc.c:3054 #2 0x080bd370 in _efree (ptr=0x15f2e5ac) at zend_alloc.c:246 #3 0x080bd703 in shutdown_memory_manager (silent=1, clean_cache=1) at zend_alloc.c:469 #4 0x0805c3ba in php_module_shutdown () at main.c:1007 #5 0x0805b05d in main (argc=2, argv=0xbb5c) at cgi_main.c:788 #6 0x400c1177 in __libc_start_main (main=0x805a748 main, argc=2, ubp_av=0xbb5c, init=0x80595b0 _init, fini=0x80e7f90 _fini, rtld_fini=0x4000e184 _dl_fini, stack_end=0xbb4c) at ../sysdeps/generic/libc-start.c:129 Also note that the program runs for many minutes (I've set the time limit to 0), but it still gives an execution time error after the last line is executed, but then it runs for a long time after that error. Reproduced this on two different computers. Stig -- PHP Development Mailing List http://www.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.1.0
I packaged PHP 4.1.0. It's based on the RC3 tag, so post-RC3 changes to the tree were *not* included. It's located on www.php.net/distributions/php-4.1.0.tar.gz Windows builders - if you can provide packages by tonight, it'd be great. I want to announce it later this evening (in approximately 15 hours). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] BC problem
Ok then, looks like we got ourselves a winner. We'll have an RC4 after all :I I'll submit the patches to revert this change and roll RC4 today. I want to hear opinions on whether this RC4 should be based on the RC3 tag, or whether it should also include the few fixes that were submitted to the branch since RC3 was rolled... If you have one, let us know about it :) Zeev At 00:50 29/11/2001, Markus Fischer wrote: On Wed, Nov 28, 2001 at 10:23:55PM +0200, Andi Gutmans wrote : Yep. As far as I remember it was reverted in 4.1.0 No, it doesn't seem to be reverted: $ ~/php410/bin/php -v 4.1.0 $ ~/php410/bin/php -f include_it.php 1br 2br br include_me.php(10) : Fatal error - Cannot redeclare cant_be_redefined() - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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] BC problem
Can you verify that this problem is gone in the latest CVS of PHP_4_0_7
(make sure you update the Zend directory)
Zeev
At 20:05 28/11/2001, Markus Fischer wrote:
A small example which shows that BC seems to be broken for a
certain (but not uncommon) case:
cat include_me.php
?
if (!defined('I_AM_INCLUDED')) {
define('I_AM_INCLUDED', 1);
} else {
echo returningbr\n;
return;
}
function cant_be_redefined() {
}
?
cat include_it.php
?
echo 1br\n;
include 'include_me.php';
echo 2br\n;
include 'include_me.php';
echo 3br\n;
?
Now run include_it.php (it doesn't matter if its CGI or
module):
On PHP 4.0.4pl1 up to 4.0.6 this gives:
1br
2br
returningbr
3br
But now I get:
1br
2br
br /
Fatal error - Cannot redeclare cant_be_redefined()
(previously declared in include_me.php:9)
[I shortened the error message to be more readable]
If this is 'now the way it is' this should be mentioned
somewhere very clearly I think. Doesn't seem to be fixable in
some way? Couldn't find a reference to it e.g. in the NEWS
file.
I know that there should be used include_once() but
I'm talking about existing code writing that way which
definitely won't work without modifications.
- Markus
ps: thanks to Jan for verifying this!
--
Please always Cc to me when replying to me on the lists.
--
PHP Development Mailing List http://www.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] Patch: Nested comments
At 03:43 29/11/2001, John Donagher wrote: On Wed, 28 Nov 2001, Robinson, Mike wrote: BC may not be of grave concern to Python developers. Perhaps thats why it hasn't hit the radar screens. You don't get to 6.5 million domains and a million ip addresses chomping big 'BC' pieces off of developers butts. Two completely different user domains; you can't measure Python usage by mod_python installs. Just like you can't measure Perl usage by mod_perl installs. How do you measure Python's success? I think that many people will argue that PHP's space is much more difficult than that of Python's, and would be much less open to such changes. In my opinion, it's quite clear that breaking compatibility is a bad idea, and breaking more things is always worse than breaking less things (hence the 'hey, we're breaking compatibility in a couple of things, so it means we can break many more things' approach is bogus). Every single thing that we break means one more thing for people to watch for when they upgrade, and more broken things means more time for migration, or, in reality, it means that people won't migrate at all. Typically, you start a revolution if things go really bad, beyond your ability to handle them. We came the closest, IMHO, with the register_globals issue - and there too, we're deprecating this feature very gradually, and still give people the option of saying 'I don't care, I want it to stay on'. This is clearly not the case with PHP, which is growing and growing through its regular evolution. It may be the case with your particular project, and some other projects, but it still doesn't mean that we can afford to break PHP in order to make it more hospitable to such projects. 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] BC problem
I don't believe so. They should be either, as Apache 2.0 is alpha code... Zeev At 16:09 29/11/2001, Brian Moon wrote: Are the changes that make Apache 2.0.28 work included in those changes? Brian. - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Markus Fischer [EMAIL PROTECTED] Cc: Andi Gutmans [EMAIL PROTECTED]; Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 4:09 AM Subject: Re: [PHP-DEV] BC problem | Ok then, looks like we got ourselves a winner. We'll have an RC4 after all :I | I'll submit the patches to revert this change and roll RC4 today. I want | to hear opinions on whether this RC4 should be based on the RC3 tag, or | whether it should also include the few fixes that were submitted to the | branch since RC3 was rolled... If you have one, let us know about it :) | | Zeev | | At 00:50 29/11/2001, Markus Fischer wrote: | On Wed, Nov 28, 2001 at 10:23:55PM +0200, Andi Gutmans wrote : | Yep. As far as I remember it was reverted in 4.1.0 | | No, it doesn't seem to be reverted: | | $ ~/php410/bin/php -v | 4.1.0 | $ ~/php410/bin/php -f include_it.php | 1br | 2br | br | include_me.php(10) : Fatal error - Cannot redeclare cant_be_redefined() | | - Markus | | -- | PHP Development Mailing List http://www.php.net/ | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | To contact the list administrators, e-mail: [EMAIL PROTECTED] | | | -- PHP Development Mailing List http://www.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] BC problem
HEAD is very far away from 4.1.0. Apache 2.0 moves between Alpha and Beta, and this isn't necessarily a unidirectional move :) This won't be in 4.1.0. Zeev At 18:11 29/11/2001, Brian Moon wrote: 2.0.28 brought it into beta. Current HEAD of PHP works fine. I just thought if there is going to be a release of PHP we might want it to work with all the latest builds if possible. The code is there in HEAD. Brian. - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: Markus Fischer [EMAIL PROTECTED]; Andi Gutmans [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 8:14 AM Subject: Re: [PHP-DEV] BC problem I don't believe so. They should be either, as Apache 2.0 is alpha code... Zeev At 16:09 29/11/2001, Brian Moon wrote: Are the changes that make Apache 2.0.28 work included in those changes? Brian. - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Markus Fischer [EMAIL PROTECTED] Cc: Andi Gutmans [EMAIL PROTECTED]; Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 4:09 AM Subject: Re: [PHP-DEV] BC problem | Ok then, looks like we got ourselves a winner. We'll have an RC4 after all :I | I'll submit the patches to revert this change and roll RC4 today. I want | to hear opinions on whether this RC4 should be based on the RC3 tag, or | whether it should also include the few fixes that were submitted to the | branch since RC3 was rolled... If you have one, let us know about it :) | | Zeev | | At 00:50 29/11/2001, Markus Fischer wrote: | On Wed, Nov 28, 2001 at 10:23:55PM +0200, Andi Gutmans wrote : | Yep. As far as I remember it was reverted in 4.1.0 | | No, it doesn't seem to be reverted: | | $ ~/php410/bin/php -v | 4.1.0 | $ ~/php410/bin/php -f include_it.php | 1br | 2br | br | include_me.php(10) : Fatal error - Cannot redeclare cant_be_redefined() | | - Markus | | -- | PHP Development Mailing List http://www.php.net/ | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | To contact the list administrators, e-mail: [EMAIL PROTECTED] | | | -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] PHP 4.1.0RC4
I plan to roll it quite soon. I'm still waiting for people to ack that the problem they complained about is gone... Zeev At 20:36 29/11/2001, Zak Greant wrote: Hello QAers, If anyone missed the thread on the PHP Dev list, it looks like we will be testing another RC of PHP 4.1.0. There is no word on when the RC will be rolled yet - I expect that Zeev (or someone) will send a message to the list when the RC is ready. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Quality Assurance Mailing List http://www.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] BC problem
Nope :) At 09:19 30/11/2001, Jani Taskinen wrote: As a minor cosmetic detail, could you set the version for the 'next' release of 4.1 to be 4.1.1 ? Many people have downloaded the broken 'release' of 4.1.0 now so we have to be able to know what version people are using when they submit bug reports. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] BC problem
Yep :) At 13:53 30/11/2001, Markus Fischer wrote: On Fri, Nov 30, 2001 at 01:40:54PM +0200, Zeev Suraski wrote : Nope :) But you can update the NEWS file to say '4.1' and not '4.0' at the top X-D - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.1.0RC4
http://www.php.net/~zeev/php-4.1.0RC4.tar.gz The plan is to release Monday, unless a real earth quaker is found... 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] ldap_first_attribute() and ldap_next_attribute() broken in 4.1.0 RCs
At 16:22 01/12/2001, Stig Venaas wrote: On Sat, Dec 01, 2001 at 03:00:44PM +0200, Zeev Suraski wrote: This is so unbelievable. It looks as if there's a higher force putting all its weight to prevent 4.1.0 from ever coming out. Yes, I really wish I noticed this before. But then it's a higher force, so who can blame you.. :) Did you MFH the fix? I've now committed it to the PHP_4_0_7 branch (v 1.94.2.3)). It hasn't got any tags though, not sure how to do that. I suppose I should have given it the tags php_4_1_0RC5 and php_4_1_0. Maybe you could tell me how? Just make sure the fix is in the PHP_4_0_7, and that would be enough... I'll create RC5 later today from the latest version of this branch. And I'm a bit curious what MFH is (merge ...?). Merge From HEAD... 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] 4.1.0 CVS RC4 has -02 option with --enable-debug ?
At 00:56 02/12/2001, Yasuo Ohgaki wrote: Is this change is intended? Is it a change? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] 4.1.0RC5
Does it work with 4.0.6? If it behaves the same, it's not a
showstopper. Basically, 4.1.0 comes out based on RC5 unless we find things
that
(a) Break things that used to work in a previous version, for a potentially
large number of people, or
(b) Pose a huge security risk or a major stability problem
Unbuffered queries were introduced in 4.0.6, so if they broke in 4.1.0, it
may be necessary to fix. If the status hasn't changed, then it can wait
for 4.2.0.
Zeev
At 12:32 04/12/2001, Derick Rethans wrote:
Hello,
yes yes... I can still win my bet :)
The following script:
?php
$query = 'SELECT * FROM users';
mysql_connect ('localhost', 'db_user', 'db_pass');
mysql_select_db ('ecommerce');
$res = mysql_unbuffered_query ($query);
while ($row = mysql_fetch_row ($res)) {
echo $row[0].\n;
}
$res = mysql_unbuffered_query ($query);
while ($row = mysql_fetch_row ($res)) {
echo $row[0].\n;
}
?
makes PHP never end (it 'hangs' on a network thing). Database and queries
make no difference.
Used versions:
PHP 4.1.0 RC5
MySQL 3.23.44 MAX (Both InnoDB and MyISAM tables)
Bundled MySQL libraries (I'm now building with non-bundled libs)
regards,
Derick
On Mon, 3 Dec 2001, Zeev Suraski wrote:
You know the drill, but practice makes perfect!
In a divine effort to prevent both Derick and Zak from winning their bets
(Derick bet we'll go up to RC8, Zak bet that we'll go as far as RC7),
please folks, FIND NO BUGS! It's a 'final release' darn it :)
Zeev
--
PHP Quality Assurance Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Derick Rethans
-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
Boulevard Heuvelink 102 - 6828 KT Arnhem - 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] Re: [PHP-QA] 4.1.0RC5
At 13:25 04/12/2001, Derick Rethans wrote: IMO, they still need to be fixed, but not in 4.1.0. Definitely :) 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] PHP can't compare...
I don't think that a PR like the one you raise is likely. Mostly all other languages behave in the same way. Even other software components, such as databases, often have this issue, unless you use string base representation. Zeev At 20:03 06/12/2001, George Whiffen wrote: Matthew, You are absolutely right, we have to do something about handling money better before anyone else notices that 0.7 plus 0.1 is not 0.8 with php! (I've already had an e-commerce user notice that their account balance is misquoted because 82 - 2 became 79 because of this). Looking through this thread it seems : 1. Floating points are not accurate, floating point arithmetic is not accurate enough for money calculations. 2. Zeev is worried that a string based type would create performance problems. 3. The standard approach when programming in low-level languages such as C or Java, is to convert to pennies and rely on integer arithmetic. 4. bc calculations/comparisons are safe. 5. Something funny is already happening in php with decimals i.e. print 1 * 0.1 is always 0.1 and never 0.1001 or whatever else has the same binary representation. My questions are: 1. Is it useful to cut down the money problem to the bare esentials? e.g. - only handle addition/subtraction/multiplication - never worry about more than 2 decimal places - maximum values could be practically limited to a billion or so 2. Could we use integer arithmetic for money, given the above restrictions? We only have to spot a money field and carry out integer arithmetic rather than floating point arithmetic. Of course we need to multiply the operands by 100 before the addition and divide by 100 at the end. Would that bring back the floating point problem in a new guise? 3. How does mysql get away with it? I've never had a smidgeon of trouble with mysql adding decimals. In fact, my safe fall back for my bug will be to get mysql to do all the arithmetic rather than php. 4. How bad could performance get? How much non-integer, non-money, floating point calculation is really done in php code? Apart from some gd stuff, I can't think when I ever actually do a non-integer, non-money calculation! 5. If actual overall impact on php applications is not too bad, (even if we slow floating point by a factor of ten), could we just use bc routines for all floating point? Perhaps it could be a configuration option, with the default as precise calculation i.e. use bc, and an option for fast i.e. non-bc calculation? Let me say again, if we want to be treated seriously as a credible HIGH LEVEL language, let alone a reliable e-commerce platform it is NOT ACCEPTABLE that (int) 10 * 0.7 + 0.1 is 7. It doesn't matter how much documentation we create, it's just not on as default behaviour. So we have to do something! The alternative is that sooner or later we'll be reading a press release from Seattle that runs something like this... PHP dangerous for e-commerce Reports are coming in of serious failings at e-commerce sites using php. These result from fundamental weaknesses in php's basic arithmetic on monetary figures. Accounting integrity is acknowledged to be completely compromised if developers rely on default php arithmetic. Even calculations such as 8.20 - 0.20 are not dependable. The problems are particularly dangerous because they are intermittent. Php's development team have been aware of this for over a year and despite their much vaunted open source rapid response, there is no fix, nor even any intention of a fix to this problem. Instead they choose to highlight weaknesses in their underlying C platform. Bigsoft CEO, Robert Doorways comments : This totally vindicates our view that Open Source technologies must not be relied upon for professional corporate applications. Only the most experienced and highly resourced software suppliers have the understanding and capability to deliver to the corporate market. We fully sympathise with customers who have been taken in by the exaggerated claims of the Open Source movement. We have set up a special php translation facilities for everyone who wants to convert their php applications to a more stable language. At BigSoft we have been counting our own and especially other people's money from our earliest days, and are specialists in big money calculations... George Matthew Hagerty wrote: At 12:09 PM 12/5/2001 +0200, Zeev Suraski wrote: At 00:38 05/12/2001, Matthew Hagerty wrote: Okay, then why when I ask PHP to show me the value of $fFloat1, do I get this: printf(%f, $fFloat1); - 63.67 Not some long draw out number like 63.671 or even 63.669... If PHP uses precision past the 6 digit then it needs to show me that it does. I can't agree with your reason because computers are not that imprecise. They are. Generally, the equality operator on floats is inaccurate by definition, you
Re: [PHP-DEV] PHP can't compare...
At 00:38 05/12/2001, Matthew Hagerty wrote: Okay, then why when I ask PHP to show me the value of $fFloat1, do I get this: printf(%f, $fFloat1); - 63.67 Not some long draw out number like 63.671 or even 63.669... If PHP uses precision past the 6 digit then it needs to show me that it does. I can't agree with your reason because computers are not that imprecise. They are. Generally, the equality operator on floats is inaccurate by definition, you learn that in Numeric Analysis 101 :) Comparing floating point numbers should only be done by comparing ranges. E.g., something like abs($num1-$num2)0.1 Doing math with a double is the same no matter where you stick the decimal point, so why would $i = be any different than $i = .?? I'll go check the datasheet for AMD's and Intel's floating point units and see how they say number representation is supposed to be just to make sure. However, even if the number is not stored as indicated, ie. 3.551 instead of a clean 3.55000, then why does PHP take the liberty to chop off that precision when converting to a string? And why is that precision not put back on when going back to a double? It is not put back on because PHP can represent 3.55 as a clean 3.55, so the assignment of floats, ie. $fFloat = 3.55;, is coded in error in PHP's internals!? There's no clean 3.55, there simply isn't. It's just how computers work. The only way to do what you're asking for is to switch to a whole different string-based representation, which is going to slow things down very considerably. It was annoying to discover this reality for me as well when I took this course a few years ago, but it's reality all the same. You can search the Web for this issue, e.g. http://www.google.com/search?q=%22never+compare%22+%22floating+point+numbers%22 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] multiple inheritance ext
It actually hasn't been decided upon yet. Zeev At 23:37 07/12/2001, Chris Newbill wrote: Zend Engine 2 will have multiple-inheritance among other nice toys. No I don't know when it will be part of PHP) There is a mailing list for the engine, I just don't remember what it is. -Chris -Original Message- From: Matthew J Gray [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 2:07 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] multiple inheritance ext Hello, Where I work, there are 4+ php applications currently being developed by 4 different programmers. In order to try to save code, we use libraries of php code, and to make a long story short-- it would be very helpful(and necessary in one case) if we had multilpe inheritance. In order to sort of solve this problem, I've written an extension that introduces the functions multi_extend() and bind() to php. multi_extend() takes a variable number of class names(=2) as arugments. The first given class name then becomes a sub class of each successive argument. The order in which the parent classes are given matters(in case of name conflicts in the parent classes). As you may have already guessed, the extension just merges the hash tables of class entries as necessary. bind() takes the name of a class and the name of a function and binds the function to the given class. This is useful to us when the interface class of a library is a subclass of another class in the library. bind() doesn't quite work properly, but multi_extend does and I plan on adding it to the machines in our test environment. Long term, however, it would be nice if this sort of multiple inheritance functionality was part of php so it could be better maintained and developed in more competent hands. I am wondering: 1) Are we alone in wanting this sort of functionality? Would anybody else find this useful? 2) Could it be better implemented in php using keywords(extends taking a list of parent classes) and operators(::) ? 3) Why overloaded classes? It doesn't seem very straight forward from a usuability standpoint(maybe I am biased since I has such bad experience getting __sleep and __awake to work and would rather never use a __* method again). I realize the reasons for having this may be a little hard to follow, so I've attatched some examples. Thanks, Matt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proporsal for cascadable general HTTP input handler
What would be the input/output of these input handlers? Zeev At 07:19 09/12/2001, Rui Hirokawa wrote: Hi, I propose a new idea for HTTP input handler to improve security and multibyte encoding support. Currently, user input by POST/GET/Cookie is treated by internal function php_treat_variables(). Some security related work to prevent some security attack is preformed in PHP script by htmlspecialchars() and regex(). And multibyte encoding detection and translation which is necessary for multibyte enable Web application is implemented by override php_treat_variables(). My idea is to introduce some general input filter/handler for php_treat_variables(). It is a similar concept as output buffering handler. For example, if a user defined input_handler = http_input_check,mb_filter in php.ini, user defined security check handler and multibyte encoding translation are perfomed. Generally, http input check for secure transaction is really hard work and some programers might make some critical mistake. And PHP script with http input check is usually hard to read. If we can use http input handler, we can implemnt separately http input check and Web application. -- - Rui Hirokawa [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] new Zend Engine license?
It still isn't in 4.1.0 because not all of the final small issues were resolved, but it's already in the CVS for the new version. Zeev At 11:41 11/12/2001, Sterling Hughes wrote: Hi, About a month ago Zend announced that they would release the engine under a BSD-style license... I think I remember Zeev saying that the definitive version of the new license would be ready in a couple of weeks time (which could be around now :). Any updates on this issue? Cheerio, Marc. it was updated a week or two ago, check out the Zend LICENSE file for the new license. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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 can't compare...
Your suggestion does make sense, but it's probably impractical at this point, as it requires a rewrite of pretty much every function or piece of code that deals with floats. It sounds like a noble cause, but one that would have to wait for now :) Zeev At 21:12 10/12/2001, George Whiffen wrote: Rasmus Lerdorf wrote: But I don't want to do this! I want to compare php numbers, which can be either strings or floats, in php! This already works fine when the php number is passed as a string, I just want it to also work when it's passed as a float/double! Which is not possible. floor(string(8.2 - 0.2)) == 8.) Sure, this will work for exactly the same reason that floor(round(8.2 - 0.2) == 8.0) will work. What you are implying is that we should always be doing an implicit round() which is not a good idea. This should be something that is up to the developer. So why doesn't php do this cast/round for me? That's my question. Because that would impose rounding errors and remove the develpor's flexibility for controlling this exactly. -Rasmus But my suggestion only produces rounding errors when the developer is trying to operate on floats with results of precision greater than 14 decimals. These developers should already know they MUST use bc or gmp in such cases. You may say it should be up to the developer, but there is no discretion that you are leaving with the developer that can be meaningfully used! Instead you are saying that we cannot protect users who are using less than 14 decimals through rounding because of the potential loss of control for developers who are using 14 decimals or more who have ALREADY been told NOT to use this function! This strikes me as frankly bizarre! The current situation benefits noone! My suggestion benefits EVERYONE except the small set of developers using medium/high precision ( 14 decimals) for whom these functions are already inappropriate. They, therefore, lose nothing! The rest do gain, a lot! REMEMBER: This is emphatically NOT the same case as rounding floats on general arithmetic functions where the rounding errors can easily propagate, rounding then would be a VERY BAD THING. This rounding will NEVER pollute a float, since the functions/operators do not return floats! George -- PHP Development Mailing List http://www.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] new Zend Engine license?
At 12:24 11/12/2001, Marc Boeren wrote: It still isn't in 4.1.0 because not all of the final small issues were resolved Is that also the reason that on zend.com the old license is still listed on the products page? Yep. but it's already in the CVS for the new version. I just updated my tree and found the modified file, thanks :) This means I can link my proprietary app against 4.2.0-dev, but not 4.1.0, right? No, you can and always could link anything you wanted with PHP 4.x. The Zend Engine license had virtually no implications for end users of PHP. 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] new Zend Engine license?
At 12:38 11/12/2001, Marc Boeren wrote: This means I can link my proprietary app against 4.2.0-dev, but not 4.1.0, right? No, you can and always could link anything you wanted with PHP 4.x. The Zend Engine license had virtually no implications for end users of PHP. This is also true if I created a modified sapi (taken from cgi-sapi), included that and all related stuff in my app (like the required modules, etc, but also the zend engine which is part of the package) and compiled a binary for redistribution? Yep. 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] uhm.. *swallows*.. security thingy?
Would the cwd of the PHP CGI be inside the user's dir? Did you test it in a real CGI environment? Zeev At 12:23 11/12/2001, Mathieu Kooiman wrote: There's a problem with PHP cgi binaries: CaPS_ (was a CVS, so..) CaPS_ which reminds me CaPS_ remember my ranting about php.ini derick? CaPS_ (it opens ./php.ini, config_file_path/php.ini, checks PHPRC environment) CaPS_ in that order CaPS_ I got some 'friends' who work at hosters CaPS_ and they don't like that CaPS_ cos, ./php.ini will enable users to override safe mode CaPS_ made a lill patch for him so it wouldn't CaPS_ but, isn't it an idea to add --restrictive-hosting or something that'll ''activate'' that patch ? CaPS_ (limit php.ini to be in config-file-path) OpenSrc yes OpenSrc no switch OpenSrc just reverse it :) CaPS_ que CaPS_ ? OpenSrc change the order OpenSrc let the MAIN php.ini override values in PHPRC/php.ini CaPS_ it doesn't sequentially parse them CaPS_ but one OpenSrc oh OpenSrc then that need to be fixed :) CaPS_ either ./php.ini, php.ini or PHPRC OpenSrc write it to php-dev It allows users to set their own options in a ./php.ini, as in override user_dir, open_basedir and safe_mode. My default php.ini has error_reporting set to E_ALL: test.php: ?php echo $test; ? php.ini-ex: error_reporting = E_ALL ~E_NOTICE caps@anaina:~/php-4.1.0$ ./php -q test.php PHP Warning: undefined variable: test in /home/caps/php-4.1.0/test.php on line 3 caps@anaina:~/php-4.1.0$ mv php.ini-ex php.ini caps@anaina:~/php-4.1.0$ ./php -q test.php caps@anaina:~/php-4.1.0$ This was reported and discussed (on IRC) first on Nov 15 (http://bugs.php.net/bug.php?id=14071), granted.. filed incorrectly. I'd say this is quite serious when you're a hoster who only allows PHP in CGI mode. Wouter de Jong is the one who actually discovered this. -- Mathieu 'CaPS_' Kooiman [EMAIL PROTECTED] MAP Internet Services -- PHP Development Mailing List http://www.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] uhm.. *swallows*.. security thingy?
At 12:36 11/12/2001, Mathieu Kooiman wrote: On Tue, 2001-12-11 at 11:29, Zeev Suraski wrote: Would the cwd of the PHP CGI be inside the user's dir? Did you test it in a real CGI environment? Zeev Err, PHP CGI would be in /usr/local/bin/php.. Yeah, but that's not what I asked - I asked about the cwd (current working directory :) 'Wouter' tells me he has tested it in a real CGI environment. This is exploitable iff the cwd of PHP when running as a CGI is a directory under the user's control. 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] uhm.. *swallows*.. security thingy?
At 15:23 11/12/2001, Mathieu Kooiman wrote: On Tue, 2001-12-11 at 14:04, Zeev Suraski wrote: At 12:36 11/12/2001, Mathieu Kooiman wrote: On Tue, 2001-12-11 at 11:29, Zeev Suraski wrote: Would the cwd of the PHP CGI be inside the user's dir? Did you test it in a real CGI environment? Zeev Err, PHP CGI would be in /usr/local/bin/php.. Yeah, but that's not what I asked - I asked about the cwd (current working directory :) There are situaties where you have like: /opt/guide/somesite.com/cgi-bin /opt/guide/somesite.com/htdocs /opt/guide/somesite.com/logs cgi-bin and htdocs (2 possible cwds) are under user control. Yes, I know :) The big question is whether PHP, when executed by Apache (as a CGI), starts up in one of these directories, or in Apache's directory. If it starts in one of these directories - then indeed we have a problem, because it'll search this directory for the php.ini. If it starts in Apache's directory, then there's no problem. 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] Re: Headers
Go ahead... Zeev At 15:18 11/12/2001, Sebastian Bergmann wrote: Sebastian Bergmann wrote: http://www.sebastian-bergmann.de/header_changes.txt Quite some -Copyright (c) 1997, 1998, 1999, 2000 The PHP Group | +Copyright (c) 1997-2002 The PHP Group| are missing in there, sorry. -- Sebastian Bergmann http://sebastian-bergmann.de/http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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.1.0 released
At 17:16 11/12/2001, Emanuel Dejanu wrote: Hi, Zeev Suraski [zeev at zend dot com] wrote: - Revolutionary performance and stability improvements under Windows. The multithreaded server modules under Windows (ISAPI, Apache, etc.) perform as much as 30 times faster under load! We want to thank Brett Brewer and his team in Microsoft for working with us to improve PHP for Windows. This means that ISAPI is considered to be production quality? Yes, even though quite a few modules inside PHP are not yet thread safe, so if you use them, it'd crash. 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] RE: PHP 4.1.0 released
MySQL and file access should be ok. I'm not sure what you mean by URL (CURL? fopen wrappers?) At 17:48 11/12/2001, Emanuel Dejanu wrote: Can you tell me some of modules that are not thread safe? I'm using only MySQL, file access+URL. Best regards, Emanuel Dejanu -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: 11 decembrie 2001 17:37 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] RE: PHP 4.1.0 released Importance: High At 17:16 11/12/2001, Emanuel Dejanu wrote: Hi, Zeev Suraski [zeev at zend dot com] wrote: - Revolutionary performance and stability improvements under Windows. The multithreaded server modules under Windows (ISAPI, Apache, etc.) perform as much as 30 times faster under load! We want to thank Brett Brewer and his team in Microsoft for working with us to improve PHP for Windows. This means that ISAPI is considered to be production quality? Yes, even though quite a few modules inside PHP are not yet thread safe, so if you use them, it'd crash. 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] Re: Headers
At 20:31 11/12/2001, Jon Parise wrote: On Tue, Dec 11, 2001 at 02:18:50PM +0100, Sebastian Bergmann wrote: http://www.sebastian-bergmann.de/header_changes.txt Quite some -Copyright (c) 1997, 1998, 1999, 2000 The PHP Group | +Copyright (c) 1997-2002 The PHP Group| As I understood it, it is apparently more correct to list the individual years than to use a range of dates. No, not really. 1997-2002 should be fine... 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] uhm.. *swallows*.. security thingy?
At 11:20 12/12/2001, Teodor Cimpoesu wrote: [rant++] I don't think it's a problem for a user to make a copy of the php binary somewhere in any of those dirs, where the cwd at runtime is a writeable dir... Well, if he can run arbitrary files from his own directories, you're screwed anyway, much more than any PHP related security exploit :) The directories from which the server agrees to run binaries are quite limited. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.1.0 released
, new installations of PHP will default to having register_globals set to off. No worries! Existing installations, which already have a php.ini file that has register_globals set to on, will not be affected. Only when you install PHP on a brand new machine (typically, if you're a brand new user), will this affect you, and then too - you can turn it on if you choose to. Note: Some of these arrays had old names, e.g. $HTTP_GET_VARS. These names still work, but we encourage users to switch to the new shorter, and auto-global versions. Thanks go to Shaun Clowes ([EMAIL PROTECTED]) for pointing out this problem and for analyzing it. - FULL LIST OF CHANGES 10 Dec 2001, Version 4.1.0 - Worked around a bug in the MySQL client library that could cause PHP to hang when using unbuffered queries. (Zeev) - Fixed a bug which caused set_time_limit() to affect all subsequent requests to running Apache child process. (Zeev) - Removed the sablotron extension in favor of the new XSLT extension. (Sterling) - Fixed a bug in WDDX deserialization that would sometimes corrupt the root element if it was a scalar one. (Andrei) - Make ImageColorAt() and ImageColorsForIndex() work with TrueColor images. (Rasmus) - Fixed a bug in preg_match_all() that would return results under improper indices in certain cases. (Andrei) - Fixed a crash in str_replace() that would happen if search parameter was an array and one of the replacements resulted in subject string being empty. (Andrei) - Fixed MySQL extension to work with MySQL 4.0. (Jani) - Fixed a crash bug within Cobalt systems. Patch by [EMAIL PROTECTED] (Jani) - Bundled Dan Libby's xmlrpc-epi extension. - Introduced extension version numbers. (Stig) - Added version_compare() function. (Stig) - Fixed pg_last_notice() (could cause random crashes in PostgreSQL applications, even if they didn't use pg_last_notice()). (Zeev) - Fixed DOM-XML's error reporting, so E_WARNING errors are given instead of E_ERROR error's, this allows you to trap errors thrown by DOMXML functions. (Sterling) - Fixed a bug in the mcrypt extension, where list destructors were not properly being allocated. (Sterling) - Better Interbase blob, null and error handling. (Patch by Jeremy Bettis) - Fixed a crash bug in array_map() if the input arrays had string or non-sequential keys. Also modified it so that if a single array is passed, its keys are preserved in the resulting array. (Andrei) - Fixed a crash in dbase_replace_record. (Patch by [EMAIL PROTECTED]) - Fixed a crash in msql_result(). (Zeev) - Added support for single dimensional SafeArrays and Enumerations. Added an is_enum() function to check if a component implements an enumeration. (Alan, Harald) - Fixed a bug in dbase_get_record() and dbase_get_record_with_names(). boolean fields are now returned correctly. Patch by Lawrence E. Widman [EMAIL PROTECTED] (Jani) - Added --version option to php-config. (Stig) - Improved support for thttpd-2.21b by incorporating patches for all known bugs. (Sascha) - Added ircg_get_username, a roomkey argument to ircg_join, error fetching infrastructure, a tokenizer to speed up message processing, and fixed a lot of bugs in the IRCG extension. (Sascha) - Improved speed of the serializer/deserializer. (Thies, Sascha) - Floating point numbers are better detected when converting from strings. (Zeev, Zend Engine) - Replaced php.ini-optimized with php.ini-recommended. As the name implies, it's warmly recommended to use this file as the basis for your PHP configuration, rather than php.ini-dist. (Zeev) - Restore xpath_eval() and php_xpathptr_eval() for 4.0.7. There are still some known leaks. (Joey) - Added import_request_variables(), to allow users to safely import form variables to the global scope (Zeev) - Introduced a new $_REQUEST array, which includes any GET, POST or COOKIE variables. Like the other new variables, this variable is also available regardless of the context. (Andi Zeev) - Introduced $_GET, $_POST, $_COOKIE, $_SERVER and $_ENV variables, which deprecate the old $HTTP_*_VARS arrays. In addition to be much shorter to type - these variables are also available regardless of the scope, and there's no need to import them using the 'global' statement. (Andi Zeev) - Added vprintf() and vsprintf() functions that allow passing all arguments after format as an array. (Andrei) - Added support for GD2 image type for ImageCreateFromString() (Jani) - Added ImageCreateFromGD(), ImageCreateFromGD2(), ImageCreateFromGD2part(), ImageGD() and ImageGD2() functions (Jani) - addcslashes now warns when charlist is invalid. The returned string remained the same (Jeroen) - Added optional extra argument to gmp_init(). The extra argument indicates which number base gmp should use when converting a string to the gmp-number. (Troels) - Added the Cyrus-IMAP extension, which allows
[PHP-DEV] PHP 4.1.0 released
, new installations of PHP will default to having register_globals set to off. No worries! Existing installations, which already have a php.ini file that has register_globals set to on, will not be affected. Only when you install PHP on a brand new machine (typically, if you're a brand new user), will this affect you, and then too - you can turn it on if you choose to. Note: Some of these arrays had old names, e.g. $HTTP_GET_VARS. These names still work, but we encourage users to switch to the new shorter, and auto-global versions. Thanks go to Shaun Clowes ([EMAIL PROTECTED]) for pointing out this problem and for analyzing it. - FULL LIST OF CHANGES 10 Dec 2001, Version 4.1.0 - Worked around a bug in the MySQL client library that could cause PHP to hang when using unbuffered queries. (Zeev) - Fixed a bug which caused set_time_limit() to affect all subsequent requests to running Apache child process. (Zeev) - Removed the sablotron extension in favor of the new XSLT extension. (Sterling) - Fixed a bug in WDDX deserialization that would sometimes corrupt the root element if it was a scalar one. (Andrei) - Make ImageColorAt() and ImageColorsForIndex() work with TrueColor images. (Rasmus) - Fixed a bug in preg_match_all() that would return results under improper indices in certain cases. (Andrei) - Fixed a crash in str_replace() that would happen if search parameter was an array and one of the replacements resulted in subject string being empty. (Andrei) - Fixed MySQL extension to work with MySQL 4.0. (Jani) - Fixed a crash bug within Cobalt systems. Patch by [EMAIL PROTECTED] (Jani) - Bundled Dan Libby's xmlrpc-epi extension. - Introduced extension version numbers. (Stig) - Added version_compare() function. (Stig) - Fixed pg_last_notice() (could cause random crashes in PostgreSQL applications, even if they didn't use pg_last_notice()). (Zeev) - Fixed DOM-XML's error reporting, so E_WARNING errors are given instead of E_ERROR error's, this allows you to trap errors thrown by DOMXML functions. (Sterling) - Fixed a bug in the mcrypt extension, where list destructors were not properly being allocated. (Sterling) - Better Interbase blob, null and error handling. (Patch by Jeremy Bettis) - Fixed a crash bug in array_map() if the input arrays had string or non-sequential keys. Also modified it so that if a single array is passed, its keys are preserved in the resulting array. (Andrei) - Fixed a crash in dbase_replace_record. (Patch by [EMAIL PROTECTED]) - Fixed a crash in msql_result(). (Zeev) - Added support for single dimensional SafeArrays and Enumerations. Added an is_enum() function to check if a component implements an enumeration. (Alan, Harald) - Fixed a bug in dbase_get_record() and dbase_get_record_with_names(). boolean fields are now returned correctly. Patch by Lawrence E. Widman [EMAIL PROTECTED] (Jani) - Added --version option to php-config. (Stig) - Improved support for thttpd-2.21b by incorporating patches for all known bugs. (Sascha) - Added ircg_get_username, a roomkey argument to ircg_join, error fetching infrastructure, a tokenizer to speed up message processing, and fixed a lot of bugs in the IRCG extension. (Sascha) - Improved speed of the serializer/deserializer. (Thies, Sascha) - Floating point numbers are better detected when converting from strings. (Zeev, Zend Engine) - Replaced php.ini-optimized with php.ini-recommended. As the name implies, it's warmly recommended to use this file as the basis for your PHP configuration, rather than php.ini-dist. (Zeev) - Restore xpath_eval() and php_xpathptr_eval() for 4.0.7. There are still some known leaks. (Joey) - Added import_request_variables(), to allow users to safely import form variables to the global scope (Zeev) - Introduced a new $_REQUEST array, which includes any GET, POST or COOKIE variables. Like the other new variables, this variable is also available regardless of the context. (Andi Zeev) - Introduced $_GET, $_POST, $_COOKIE, $_SERVER and $_ENV variables, which deprecate the old $HTTP_*_VARS arrays. In addition to be much shorter to type - these variables are also available regardless of the scope, and there's no need to import them using the 'global' statement. (Andi Zeev) - Added vprintf() and vsprintf() functions that allow passing all arguments after format as an array. (Andrei) - Added support for GD2 image type for ImageCreateFromString() (Jani) - Added ImageCreateFromGD(), ImageCreateFromGD2(), ImageCreateFromGD2part(), ImageGD() and ImageGD2() functions (Jani) - addcslashes now warns when charlist is invalid. The returned string remained the same (Jeroen) - Added optional extra argument to gmp_init(). The extra argument indicates which number base gmp should use when converting a string to the gmp-number. (Troels) - Added the Cyrus-IMAP extension, which allows
[PHP-DEV] Re: [PHP] Re: PHP 4.1.0 released
They'll be posted within a couple of days.
Zeev
At 07:42 11/12/2001, MindHunter wrote:
Where do we get the Windows Binaries?
Cheers
MH
Zeev Suraski [EMAIL PROTECTED] wrote in message
5.1.0.14.2.20011210234236.0516bec0@localhost">news:5.1.0.14.2.20011210234236.0516bec0@localhost...
After a lengthy QA process, PHP 4.1.0 is finally out. Download at
http://www.php.net/downloads.php !
PHP 4.1.0 includes several other key improvements:
- A new input interface for improved security (read below)
- Highly improved performance in general
- Revolutionary performance and stability improvements under Windows. The
multithreaded server modules under Windows (ISAPI, Apache, etc.) perform
as
much as 30 times faster under load! We want to thank Brett Brewer and his
team in Microsoft for working with us to improve PHP for Windows.
- Versioning support for extensions. Right now it's barely being used,
but
the infrastructure was put in place to support separate version numbers
for
different extensions. The negative side effect is that loading extensions
that were built against old versions of PHP will now result in a crash,
instead of in a nice clear message. Make sure you only use extensions
built with PHP 4.1.0.
- Turn-key output compression support
- *LOTS* of fixes and new functions
As some of you may notice, this version is quite historical, as it's the
first time in history we actually incremented the middle digit! :) The
two
key reasons for this unprecedented change were the new input interface,
and
the broken binary compatibility of modules due to the versioning support.
Following is a description of the new input mechanism. For a full list of
changes in PHP 4.1.0, scroll down to the end of this section.
---
SECURITY: NEW INPUT MECHANISM
First and foremost, it's important to stress that regardless of anything
you may read in the following lines, PHP 4.1.0 *supports* the old input
mechanisms from older versions. Old applications should go on working
fine
without modification!
Now that we have that behind us, let's move on :)
For various reasons, PHP setups which rely on register_globals being on
(i.e., on form, server and environment variables becoming a part of the
global namespace, automatically) are very often exploitable to various
degrees. For example, the piece of code:
?php
if (authenticate_user()) {
$authenticated = true;
}
...
?
May be exploitable, as remote users can simply pass on 'authenticated' as
a
form variable, and then even if authenticate_user() returns false,
$authenticated will actually be set to true. While this looks like a
simple example, in reality, quite a few PHP applications ended up being
exploitable by things related to this misfeature.
While it is quite possible to write secure code in PHP, we felt that the
fact that PHP makes it too easy to write insecure code was bad, and we've
decided to attempt a far-reaching change, and deprecate
register_globals. Obviously, because the vast majority of the PHP code in
the world relies on the existence of this feature, we have no plans to
actually remove it from PHP anytime in the foreseeable future, but we've
decided to encourage people to shut it off whenever possible.
To help users build PHP applications with register_globals being off,
we've
added several new special variables that can be used instead of the old
global variables. There are 7 new special arrays:
$_GET - contains form variables sent through GET
$_POST - contains form variables sent through POST
$_COOKIE - contains HTTP cookie variables
$_SERVER - contains server variables (e.g., REMOTE_ADDR)
$_ENV - contains the environment variables
$_REQUEST - a merge of the GET variables, POST variables and Cookie
variables. In other words - all the information that is coming from the
user, and that from a security point of view, cannot be trusted.
$_SESSION - contains HTTP variables registered by the session module
Now, other than the fact that these variables contain this special
information, they're also special in another way - they're automatically
global in any scope. This means that you can access them anywhere,
without
having to 'global' them first. For example:
function example1()
{
print $_GET[name]; // works, 'global $_GET;' is not necessary!
}
would work fine! We hope that this fact would ease the pain in migrating
old code to new code a bit, and we're confident it's going to make writing
new code easier. Another neat trick is that creating new entries in the
$_SESSION array will automatically register them as session variables, as
if you called session_register(). This trick is limited to the session
module only - for example, setting new entries in $_ENV will *not* perform
an implicit putenv().
PHP 4.1.0 still defaults
Re: [PHP-DEV] [defacementmonitor@hotmail.com: Win ME, Apache/1.3.20 and PHP/4.0.4pl1 Source disclosure Vulnerability]
As I responded on Bugtraq, this is, if anything, an Apache bug, not a PHP bug. It could be a configuration bug too, but the bottom line is the Apache doesn't determine that the file is a PHP file when requested in that way, and doesn't even invoke PHP on it. Zeev At 02:42 16/12/2001, Markus Fischer wrote: Hi, This mail just poppep up buqtrag. Although PHP 4.0.4pl1 is old and it is unlikely someone is running it on a production machine on Win ME I'ld like someone with access to Win ME and standard Apache/PHP installation can verify this is true or not. Not only PHP 4.0.4pl1 but also 4.1.0 would be interesting. - Markus -- Please always Cc to me when replying to me on the lists. Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 18662 invoked from network); 15 Dec 2001 19:43:00 - Received: from outgoing2.securityfocus.com (HELO outgoing.securityfocus.com) (66.38.151.26) by chello213047128070.15.vie.surfer.at with SMTP; 15 Dec 2001 19:43:00 - Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id 7F25B8F2AF; Sat, 15 Dec 2001 12:27:16 -0700 (MST) Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Id: bugtraq.list-id.securityfocus.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: moderator for [EMAIL PROTECTED] Received: (qmail 29165 invoked from network); 15 Dec 2001 02:52:16 - Date: 15 Dec 2001 01:26:49 - Message-ID: [EMAIL PROTECTED] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: Bill Q [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Win ME, Apache/1.3.20 and PHP/4.0.4pl1 Source disclosure Vulnerability It appears as if PHP/4.0.4 installed on Win ME running Apache/1.3.20 will disclose php source if the url is entered with pounds surrounding the dot. http://server.com/phpfile#.#php I have tested this on: Apache/1.3.22 (Win32) PHP/4.0.6 (Win2K pro) And it is not vulnerable. This may be a Win ME thing.. I would be curious if Apache/1.3.22 on Win ME is vulnerable Now WHY someone would have a webserver on MEis another question -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
At 02:06 16/12/2001, [EMAIL PROTECTED] wrote: As always I am trying to be constructive here. Me too! I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. I think we're all well aware of this fact. I definitely am. I can also understand their reasons - updating to the last version is not suitable for everyone. If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. Being aware or even sensitive to this point has very little to do with the specific issue at hand (dirname()). We do try to minimize incompatibilities in released, documented code, but sometimes they do occur. You'd find that's the case with virtually any large scale piece of software, including commercial software. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. I know, I'm just pointing out that I'm hearing that mostly from you and nobody else :) I can assure you that I'm not in 'ignore mlemos' mode, and you would have gotten a very similar answer (well, except for the 'Manuel,' in the beginning) if you were somebody else. You're more than welcome to send us what you think is constructive criticism. 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]
