Re: [PHP-DEV] readfile() memory usage
On Tue, May 1, 2012 at 8:44 PM, Paul Reinheimer preinhei...@gmail.com wrote: Hi, It sounds like it. In that case the memory spike is happening in the output buffer, where the file is streamed into by readfile() in 8K chunks until the output buffer explodes. :-) So, I think we're back to urban legend territory. That's good to know. Thanks, and my apologies for adding confusion to the issue. One question, with a value of 4096 for the ini directive, shouldn't it be flushing data to the client long before I run into memory issues? What have I missed here. That's an interesting catch, and the answer is here :http://lxr.php.net/opengrok/xref/PHP_5_3/main/output.c#596 In fact, even if your ob layer is , say , 4K length, PHP will reallocate it to fit the data written in it (http://lxr.php.net/opengrok/xref/PHP_5_3/main/output.c#395) with a block_size step (http://lxr.php.net/opengrok/xref/PHP_5_3/main/output.c#402) In short, having an output_buffer of, say, 4K lenght, will not prevent PHP to allocate several Mb of data if the OB layer gets suddenly fed with such amount of data, what readfile() with MMAP strategy does actually. Mike could help as he's the main ob layer designer. Bye :) Julien.Pauli -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi Everyone So, I think we're back to urban legend territory. I've updated the documentation for readfile() to help send more people down the path of checking for output buffering, and disabling that rather than contriving loops with fread(). http://docs.php.net/readfile paul -- Paul Reinheimer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 5/2/2012 10:03 PM, Galen Wright-Watson wrote:
On Wed, May 2, 2012 at 5:23 AM, C.Koycan5...@gmail.com wrote:
On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
On Thu, Apr 26, 2012 at 3:45 AM, C.Koycan5...@gmail.com wrote:
As of 5.3.0 this bug does not exist for function names. Only classes and
interfaces.
Turns out, if you cause a function to be called dynamically by (e.g.)
using
a variable function, the bug will surface.
?php
setlocale(LC_CTYPE, 'tr_TR');
function IJK() {}
# succeeds
IJK();
If literal function call precedes the function definition, that would fail
too in 5.2.17, but not in 5.3.0.
What has changed in this regard 5.2-5.3 ?
Do you mean something like the following?
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
setlocale(LC_CTYPE, 'en_US');
function IJK() {echo __FUNCTION__, \n;}
I couldn't get it to generate an error under PHP 5.2.17. What am I missing?
Try this with 5.2.17:
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
function IJK() {}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Enforcing final in traits
This caused a few bugs for us / confusion. The final keyword is accepted inside a trait but it the class also defines a method without the final keyword this takes precedence. Two solutions: Enforce final when a trait defines - https://whisky.macvicar.net/patches/0001-If-a-trait-declares-a-method-as-final-enforce-that.patch Prohibit final form being used in a trait - https://whisky.macvicar.net/patches/002-traits-Disable-use-of-final-keyword.patch I'm for the first solution here - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Wed, May 2, 2012 4:43 am, Pierre Joye wrote: empty() on the other hand, tests if something is empty, and only if it is empty. The result of an expression can be empty. an expression can also have a value of null. And NULL is empty. No issue here. Expressions can also return , 0, 0.0, 0, array() You really think those should all be empty? Or you want different behavior for expressions vs variables. I'm assuming virtually everybody would agree THAT is unacceptable... Or are the rules for what is or isn't empty going to also change. Again. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Fri, May 4, 2012 at 11:48 AM, Richard Lynch c...@l-i-e.com wrote: On Wed, May 2, 2012 4:43 am, Pierre Joye wrote: empty() on the other hand, tests if something is empty, and only if it is empty. The result of an expression can be empty. an expression can also have a value of null. And NULL is empty. No issue here. Expressions can also return , 0, 0.0, 0, array() You really think those should all be empty? Unless I'm missing something here, aren't all those things already considered to be empty?? Here's what the PHP man page for empty() says: The following things are considered to be empty: - ** (an empty string) - *0* (0 as an integer) - *0.0* (0 as a float) - *0* (0 as a string) - *NULL* - *FALSE* - *array()* (an empty array) - *var $var;* (a variable declared, but without a value in a class) If that's the way it already behaves, then why would keeping it that way even be an issue? If an expression returns any of those things, it's empty. I've been following the debate and I'm still a bit unclear as to what the benefit would be to allowing non-variables in isset(). I mean, as was stated earlier, expressions are neither set nor unset. Furthermore, if you were to assign a variable to any valid expression (empty or otherwise), it would be considered set. Therefore, through simple deductive logic, would an expression passed to isset() not, by definition, *always* return TRUE if the expression itself is syntactically valid? The answer seems to be yes as far as I can tell. And if that is the case, then what value is there in allowing it if the return value is always the same no matter what? --Kris
Re: [PHP-DEV] Enforcing final in traits
On Fri, May 4, 2012 at 8:30 PM, Scott MacVicar sc...@macvicar.net wrote: This caused a few bugs for us / confusion. The final keyword is accepted inside a trait but it the class also defines a method without the final keyword this takes precedence. it also ignores visibility abstract and static.. I thought this was intentional? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
I've been following the debate and I'm still a bit unclear as to what the benefit would be to allowing non-variables in isset(). I mean, as was stated earlier, expressions are neither set nor unset. Furthermore, if you were to assign a variable to any valid expression (empty or otherwise), it would be considered set. Therefore, through simple deductive logic, would an expression passed to isset() not, by definition, *always* return TRUE if the expression itself is syntactically valid? yeah, this wouldn't be much to think about if isset in php wouldn't handle null values as not set. and as I mentioned expressions can return null, so it isn't true that any expression given to isset would always result in true. but I think we were talked this over already, so not much point repeating the same arguments over and over again. to summarize, the following cons were brought up against allowing expressions for isset : - if you pass an undefined constant to isset, you will get unexpected result as isset will raise a notice and can return unexpected result as the constant is casted to string before being passed to isset(btw. this is how expressions work everywhere else, so it isn't a real surprise, but it is a change to the current behavior). - this is a valid concern, but the same problem applies to empty too, so it is a general problem with the current patch/rfc. I think it would be nice mentioning this in the rfc, as this could/will cause a few wtf moments for some people. - isset(CONST) could be seen as defined(CONST) but they are returning different results if CONS is defined with NULL or undefined. - this is a valid concern, and there is no good solution, for isset(CONST) we either go cosistent with isset or declared, but can't do both at the same time. - semantically empty can make sense for expressions, isset doesn't: - yep, the only thing that makes this a little less clear/obvious is the fact that isset in php also checks for value, not only the existence of the variable. - following the previous point, there are much more fluent use-cases for empty(expression) than for isset(expression) - this is true, for null check you should use comparing the value, for other cases empty could be much more useful, only the isset(CONST) could be useful, but I mentioned the problems with that above. after discussing this and thinking it over a few times, I decided that I will drop my case about supporting both empty and isset. I think that keeping the argument handling for isset and empty in sync doesn't worth the possible gotchas. and I now a little less sure about suporting this change for empty(), given how much do we emphasized over the years that empty won't trigger any warning about the non-existent variables. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Fri, May 4, 2012 at 1:27 PM, Ferenc Kovacs tyr...@gmail.com wrote: I've been following the debate and I'm still a bit unclear as to what the benefit would be to allowing non-variables in isset(). I mean, as was stated earlier, expressions are neither set nor unset. Furthermore, if you were to assign a variable to any valid expression (empty or otherwise), it would be considered set. Therefore, through simple deductive logic, would an expression passed to isset() not, by definition, *always* return TRUE if the expression itself is syntactically valid? yeah, this wouldn't be much to think about if isset in php wouldn't handle null values as not set. Hmm I'd never really thought about that before. But now that you mention it, that does sound like a problem. Honestly, I can see no value in maintaining a different standard for what constitutes a set or not-set variable depending on the function. While I understand Pierre's point that people have used $var = NULL; in the past to unset variables, I don't think we should actually be supporting that. After all, $var = (anything, including nothing) is, by definition, setting the variable to something (or nothing). I would analogize this to a printed dictionary. Let's say you look up the word, glarbofatass. It's not there. So you take out another dictionary and look it up again. There's an entry for it, but the entry says, This word has no meaning. In the first dictionary, glarbofatass is not set. In the second dictionary, glarbofatass is set to the state of having no meaning. Nevertheless, it *is* set. I've never thought of setting something to NULL as being *literally *the same thing as unsetting it (though the purpose and end result are mostly the same). If we didn't have an unset() function, I might feel differently about this. But we do, so really I don't see why = NULL needs to be an alias for unset(). To be honest, I doubt this would pose any real BC breakage, either, unless someone can point me to an instance where somebody uses = NULL to unset a variable and then checks it with isset() later, expecting FALSE. Personally, I would consider = NULL == unset() but only as it pertains to isset() to be a bug that should be fixed, not a feature that should be preserved. And if we make that change (perhaps target it for PHP 6 since it would nonetheless pose a fundamental logic change, albeit an extremely minor and low-impact one), then this RFC suddenly makes a lot more sense while allowing the scope to be limited to empty() without creating any annoying contradictions. --Kris
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On Fri, May 4, 2012 at 7:01 AM, C.Koy can5...@gmail.com wrote:
On 5/2/2012 10:03 PM, Galen Wright-Watson wrote:
On Wed, May 2, 2012 at 5:23 AM, C.Koycan5...@gmail.com wrote:
On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
On Thu, Apr 26, 2012 at 3:45 AM, C.Koycan5...@gmail.com wrote:
As of 5.3.0 this bug does not exist for function names. Only classes
and
interfaces.
Turns out, if you cause a function to be called dynamically by (e.g.)
using
a variable function, the bug will surface.
?php
setlocale(LC_CTYPE, 'tr_TR');
function IJK() {}
# succeeds
IJK();
If literal function call precedes the function definition, that would
fail
too in 5.2.17, but not in 5.3.0.
What has changed in this regard 5.2-5.3 ?
Do you mean something like the following?
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
setlocale(LC_CTYPE, 'en_US');
function IJK() {echo __FUNCTION__, \n;}
I couldn't get it to generate an error under PHP 5.2.17. What am I
missing?
Try this with 5.2.17:
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
function IJK() {}
That also ran without error for me. I'm not sure how to account for the
different behavior. Here are the details of the system that I'm using:
$ uname -a
Linux n10 3.2.6mtv10 #1 SMP Wed Mar 14 06:22:06 PDT 2012 x86_64 GNU/Linux
$ php -v
PHP 5.2.17 with Suhosin-Patch 0.9.7 (cli) (built: May 3 2012 12:16:32)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
Hmm I'd never really thought about that before. But now that you mention it, that does sound like a problem. Honestly, I can see no value in maintaining a different standard for what constitutes a set or not-set variable depending on the function. While I understand Pierre's point that people have used $var = NULL; in the past to unset variables, I don't think we should actually be supporting that. After all, $var = (anything, including nothing) is, by definition, setting the variable to something (or nothing). I would analogize this to a printed dictionary. Let's say you look up the word, glarbofatass. It's not there. So you take out another dictionary and look it up again. There's an entry for it, but the entry says, This word has no meaning. In the first dictionary, glarbofatass is not set. In the second dictionary, glarbofatass is set to the state of having no meaning. Nevertheless, it *is* set. I've never thought of setting something to NULL as being *literally *the same thing as unsetting it (though the purpose and end result are mostly the same). If we didn't have an unset() function, I might feel differently about this. But we do, so really I don't see why = NULL needs to be an alias for unset(). To be honest, I doubt this would pose any real BC breakage, either, unless someone can point me to an instance where somebody uses = NULL to unset a variable and then checks it with isset() later, expecting FALSE. Personally, I would consider = NULL == unset() but only as it pertains to isset() to be a bug that should be fixed, not a feature that should be preserved. And if we make that change (perhaps target it for PHP 6 since it would nonetheless pose a fundamental logic change, albeit an extremely minor and low-impact one), then this RFC suddenly makes a lot more sense while allowing the scope to be limited to empty() without creating any annoying contradictions. then maybe you should open a separate rfc and thread for that. btw. $foo = null; doesn't equals/aliases unset($foo); only isset() written in a way so that it checks the existence of the variable AND if it exists then checks that it's value isn't null. maybe this isn't nice for a newcommer to the language, but it is how isset works for a pretty long time now, and changing it would be a major BC break. not impossible, but that would definitively deserve a separate RFC and discussion. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Enforcing final in traits
On 04 May 2012, at 21:46, Hannes Magnusson wrote: On Fri, May 4, 2012 at 8:30 PM, Scott MacVicar sc...@macvicar.net wrote: This caused a few bugs for us / confusion. The final keyword is accepted inside a trait but it the class also defines a method without the final keyword this takes precedence. The methods in the class always take precedency. However, the final keyword might just be something I overlooked. It sounds sensible that if the final is not explicitly removed during composition to treat it as what final was meant for and check it against the methods defined in the class body as well. Scott, could you elaborate a bit of the use case of final in a trait? it also ignores visibility abstract and static.. abstract is not ignored. An abstract method in a trait expresses a requirement to the host class (using class). In general, the ppp visibilities are seen as hints for the standard usage of a trait, but can be changed during composition. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
