RE: [PHP-DEV] readfile() memory usage
Hi Larry, 4) So given #2 and #3, the readfile() will kill your memory, don't use it line is a persistent urban legend that belongs on Snopes as debunked. Looping on fread() for performance is a red herring. I implemented this earlier this very year to avoid memory issues (a quick look at project history shows me working on it in January). The difference between using readfile, and some convoluted method from the documentation comments was clear and immediate: corrupted download with out of memory error in the logs, to things working just fine. Let me re-create with a simple test script and share my server details before we call snopes :) Are you sure that you are *not* using ob_start()/ob_flush()/... (output buffering)? If this is the case, readfile writes to the output, but buffers everything in memory, as the PHP output buffering is active? Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug/Req:#61422#39003 enble Type Hint autoloading
Hi internals: danko reported this bug#61422: Lack of autoload on type hinting breaks class_alias。 now parmeter type hint DID NOT trying to autoload. I think allow it autoloading could be helpful. BUGSCommit for quick refer: - https://bugs.php.net/bug.php?id=61422 - https://bugs.php.net/bug.php?id=39003 - http://svn.php.net/viewvc?view=revisionrevision=220906 PROPOSAL(FR)： **I'm asking if we can enable type hint autoloading?** I did some homework: - Before FIX for #39003, parameter type hint will try to autoload the hint class if not found. after this fix it will not. in bug#39003: the final result was DOC Problem, seems we all agreed that it SHOULD autoloading. - But in revision: http://svn.php.net/viewvc?view=revisionrevision=220906 It was **FIXED** I try to search RFC about typehint, I didn't find anything about it. It was commited really long time ago almost 6 years ago, it would be very nice if Antony Dovgal still remember it;) REASON： Here is my reason to ask whether we can enable it: 1. Autoload will only happened when function/method calling. so does any other autoloading, I mean it wouldn't hurt performance. 2. Class will be used for sure, so trying to autoload it is reasonable: - If we need check certain Class, then we have to use the class in function/method. - most of time it already loaded*, so autoloading happened rarely. 3. If pass the wrong type and the hinted class not found this gives autoloader a change to handle it like the #61422' (https://bugs.php.net/bug.php?id=61422)s test script did. we can do something if not found. since we use the class in function/method, autoload the class is reasonable. most of the time we would not use the *FEATURE*, but it could make it more flexible. PATCH: 1. change zend_verify_arg_class_kind to autoload class 2. if class can't load, zend_fetch_class silently return (No fatal here) to give zend_verify_arg_class_kind a chance to report previous catchable_fatal_error eg： Catchable fatal error: Argument 1 passed to func() must be an instance of AX, integer given。 a simple patch attached request for comment. Finally, What do you guys think about it? Thanks. Best, -- reeze | simpie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug/Req:#61422#39003 enble Type Hint autoloading
On Tue, May 1, 2012 at 8:03 PM, reeze reeze@gmail.com wrote:
Hi internals:
danko reported this bug#61422: Lack of autoload on type hinting breaks
class_alias。
now parmeter type hint DID NOT trying to autoload. I think allow it
autoloading could be helpful.
BUGSCommit for quick refer:
- https://bugs.php.net/bug.php?id=61422
- https://bugs.php.net/bug.php?id=39003
- http://svn.php.net/viewvc?view=revisionrevision=220906
PROPOSAL(FR)：
**I'm asking if we can enable type hint autoloading?**
I did some homework:
- Before FIX for #39003, parameter type hint will try to autoload the hint
class if not found.
after this fix it will not. in bug#39003: the final result was DOC
Problem, seems we all agreed
that it SHOULD autoloading.
- But in
revision: http://svn.php.net/viewvc?view=revisionrevision=220906 It was
**FIXED**
I try to search RFC about typehint, I didn't find anything about
it. It was commited really long time ago
almost 6 years ago, it would be very nice if Antony Dovgal still
remember it;)
REASON：
Here is my reason to ask whether we can enable it:
1. Autoload will only happened when function/method calling. so does any
other autoloading,
I mean it wouldn't hurt performance.
2. Class will be used for sure, so trying to autoload it is reasonable:
- If we need check certain Class, then we have to use the class in
function/method.
- most of time it already loaded*, so autoloading happened rarely.
3. If pass the wrong type and the hinted class not found this gives
autoloader a change to handle it
like the #61422's test script did. we can do something if not found.
since we use the class in
function/method, autoload the class is reasonable. most of the time we
would not use the *FEATURE*,
but it could make it more flexible.
PATCH:
1. change zend_verify_arg_class_kind to autoload class
2. if class can't load, zend_fetch_class silently return (No fatal here) to
give zend_verify_arg_class_kind a chance
to report previous catchable_fatal_error eg：
Catchable fatal error: Argument 1 passed to func() must be an instance of
AX, integer given。
a simple patch attached request for comment.
Finally, What do you guys think about it?
Hi:
thanks for writing this, but I was a little confused, please
correct me if I mis-understand you.
if you pass a right instance of class to a function , how can that
class not be loaded already?
for example:
function foo(Foo_Bar $a) {
}
how can you pass a Foo_Bar instance to function foo without
Foo_Bar class already defined?
thanks
Thanks.
Best,
--
reeze | simpie.com
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug/Req:#61422#39003 enble Type Hint autoloading
Hi, Laruence:
I mean pass a wrong class object to a function/method. if the type
hinted Class didn't loaded, we
could try to load it. (if it's the right class, nothing happened), eg.
function func(NotFoundClass $a) {}
maybe we could pass another class instance.
$a = new DemoClass();
func($a);
It would be useful for class_alias like Bug#61422 requested.
It's a little narrow feature usage scenario，but it gives a way to handle
it. so I think
It might be useful。
if failed to autoload it raise E_CATCHABLE_FATAL, loaded class will simple
released
if user catch the E_CATABLE_FATAL, loaded class will be useful, since it
will be used later.
if loaded success everyone is happy.
On 1 May 2012 20:25, Laruence larue...@php.net wrote:
On Tue, May 1, 2012 at 8:03 PM, reeze reeze@gmail.com wrote:
Hi internals:
danko reported this bug#61422: Lack of autoload on type hinting breaks
class_alias。
now parmeter type hint DID NOT trying to autoload. I think allow it
autoloading could be helpful.
BUGSCommit for quick refer:
- https://bugs.php.net/bug.php?id=61422
- https://bugs.php.net/bug.php?id=39003
- http://svn.php.net/viewvc?view=revisionrevision=220906
PROPOSAL(FR)：
**I'm asking if we can enable type hint autoloading?**
I did some homework:
- Before FIX for #39003, parameter type hint will try to autoload the
hint
class if not found.
after this fix it will not. in bug#39003: the final result was
DOC
Problem, seems we all agreed
that it SHOULD autoloading.
- But in
revision: http://svn.php.net/viewvc?view=revisionrevision=220906 It was
**FIXED**
I try to search RFC about typehint, I didn't find anything
about
it. It was commited really long time ago
almost 6 years ago, it would be very nice if Antony
Dovgal still
remember it;)
REASON：
Here is my reason to ask whether we can enable it:
1. Autoload will only happened when function/method calling. so does any
other autoloading,
I mean it wouldn't hurt performance.
2. Class will be used for sure, so trying to autoload it is reasonable:
- If we need check certain Class, then we have to use the class in
function/method.
- most of time it already loaded*, so autoloading happened rarely.
3. If pass the wrong type and the hinted class not found this gives
autoloader a change to handle it
like the #61422's test script did. we can do something if not found.
since we use the class in
function/method, autoload the class is reasonable. most of the time
we
would not use the *FEATURE*,
but it could make it more flexible.
PATCH:
1. change zend_verify_arg_class_kind to autoload class
2. if class can't load, zend_fetch_class silently return (No fatal here)
to
give zend_verify_arg_class_kind a chance
to report previous catchable_fatal_error eg：
Catchable fatal error: Argument 1 passed to func() must be an instance of
AX, integer given。
a simple patch attached request for comment.
Finally, What do you guys think about it?
Hi:
thanks for writing this, but I was a little confused, please
correct me if I mis-understand you.
if you pass a right instance of class to a function , how can that
class not be loaded already?
for example:
function foo(Foo_Bar $a) {
}
how can you pass a Foo_Bar instance to function foo without
Foo_Bar class already defined?
thanks
Thanks.
Best,
--
reeze | simpie.com
--
Laruence Xinchen Hui
http://www.laruence.com/
--
http://reeze.cn
[PHP-DEV] Re: Bug/Req:#61422#39003 enble Type Hint autoloading
On Tue, May 1, 2012 at 9:07 PM, reeze reeze@gmail.com wrote:
Hi, Laruence:
I mean pass a wrong class object to a function/method. if the type hinted
Class didn't loaded, we
could try to load it. (if it's the right class, nothing happened), eg.
function func(NotFoundClass $a) {}
maybe we could pass another class instance.
$a = new DemoClass();
func($a);
It would be useful for class_alias like Bug#61422 requested.
Hi:
class_alias does well with type hint now, the following script :
?php
function b (Foo_Bar $a) {
echo 'okey';
}
class Dummy {
}
class_alias('Dummy', 'Foo_Bar');
b(new Dummy);
?
works find now(5.3+), output :
okey
thanks
It's a little narrow feature usage scenario，but it gives a way to handle it.
so I think
It might be useful。
if failed to autoload it raise E_CATCHABLE_FATAL, loaded class will simple
released
if user catch the E_CATABLE_FATAL, loaded class will be useful, since it
will be used later.
if loaded success everyone is happy.
On 1 May 2012 20:25, Laruence larue...@php.net wrote:
On Tue, May 1, 2012 at 8:03 PM, reeze reeze@gmail.com wrote:
Hi internals:
danko reported this bug#61422: Lack of autoload on type hinting breaks
class_alias。
now parmeter type hint DID NOT trying to autoload. I think allow it
autoloading could be helpful.
BUGSCommit for quick refer:
- https://bugs.php.net/bug.php?id=61422
- https://bugs.php.net/bug.php?id=39003
- http://svn.php.net/viewvc?view=revisionrevision=220906
PROPOSAL(FR)：
**I'm asking if we can enable type hint autoloading?**
I did some homework:
- Before FIX for #39003, parameter type hint will try to autoload the
hint
class if not found.
after this fix it will not. in bug#39003: the final result was
DOC
Problem, seems we all agreed
that it SHOULD autoloading.
- But in
revision: http://svn.php.net/viewvc?view=revisionrevision=220906 It was
**FIXED**
I try to search RFC about typehint, I didn't find anything
about
it. It was commited really long time ago
almost 6 years ago, it would be very nice if Antony
Dovgal still
remember it;)
REASON：
Here is my reason to ask whether we can enable it:
1. Autoload will only happened when function/method calling. so does any
other autoloading,
I mean it wouldn't hurt performance.
2. Class will be used for sure, so trying to autoload it is reasonable:
- If we need check certain Class, then we have to use the class
in
function/method.
- most of time it already loaded*, so autoloading happened
rarely.
3. If pass the wrong type and the hinted class not found this gives
autoloader a change to handle it
like the #61422's test script did. we can do something if not found.
since we use the class in
function/method, autoload the class is reasonable. most of the time
we
would not use the *FEATURE*,
but it could make it more flexible.
PATCH:
1. change zend_verify_arg_class_kind to autoload class
2. if class can't load, zend_fetch_class silently return (No fatal here)
to
give zend_verify_arg_class_kind a chance
to report previous catchable_fatal_error eg：
Catchable fatal error: Argument 1 passed to func() must be an instance
of
AX, integer given。
a simple patch attached request for comment.
Finally, What do you guys think about it?
Hi:
thanks for writing this, but I was a little confused, please
correct me if I mis-understand you.
if you pass a right instance of class to a function , how can that
class not be loaded already?
for example:
function foo(Foo_Bar $a) {
}
how can you pass a Foo_Bar instance to function foo without
Foo_Bar class already defined?
thanks
Thanks.
Best,
--
reeze | simpie.com
--
Laruence Xinchen Hui
http://www.laruence.com/
--
http://reeze.cn
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi Larry,
Fascinating. I even verified the md5sum of the file I got on the other end
just to be sure. I'll hold off on the blog post then. :-) I look forward
to your test setup.
The server in question is still on PHP 5.2.13
Script:
?php
ini_set('memory_limit', '8M');
$name = uniqid() . .zip;
header('Content-type: application/zip');
header(Content-Disposition: attachment; filename=\$name\);
readfile('../../filestorage/4f9e9e3b9bcff.zip');
File Information:
[user@host public]$ ls -alh ../../filestorage/4f9e9e3b9bcff.zip
-rw-r--r-- 1 apache apache 27M Apr 30 10:14 ../../filestorage/4f9e9e3b9bcff.zip
Error:
[Tue May 01 09:30:48 2012] [error] [client 198.136.162.2] PHP Fatal
error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 27617281 bytes) in
/home/lots/of/path.org/stuff/public/rf822.php on line 6
I'll try something newer, but I wanted to prove myself not crazy and
do it on the server in question first.
paul
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
On Tue, 01 May 2012 15:39:56 +0200, Paul Reinheimer preinhei...@gmail.com wrote: Fascinating. I even verified the md5sum of the file I got on the other end just to be sure. I'll hold off on the blog post then. :-) I look forward to your test setup. The server in question is still on PHP 5.2.13 [...] I'll try something newer, but I wanted to prove myself not crazy and do it on the server in question first. Unfortunately, you've ignored Uwe's e-mail... The problem is not the PHP version; the problem is that you're buffering unlimited amounts of data. Check your configuration and make sure ob_get_level() returns 0. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
I know it doesn't really fit this problem in general, but I figured I would point it out. Lighttpd introduced a brilliant concept by letting the server serve that file directly. Basically, instead of using readfile, you would just send a header: X-SendFile: $filename... It's available for Apache (as a module: http://www.jasny.net/articles/how-i-php-x-sendfile/) and NginX as well. The benefit is that the file never needs to be moved around in memory, it can be directly mapped to the network card by the OS. Just pointing it out (although it doesn't directly apply to the memory usage, it solves the problem differently, and better)... Anthony On Tue, May 1, 2012 at 9:55 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Tue, 01 May 2012 15:39:56 +0200, Paul Reinheimer preinhei...@gmail.com wrote: Fascinating. I even verified the md5sum of the file I got on the other end just to be sure. I'll hold off on the blog post then. :-) I look forward to your test setup. The server in question is still on PHP 5.2.13 [...] I'll try something newer, but I wanted to prove myself not crazy and do it on the server in question first. Unfortunately, you've ignored Uwe's e-mail... The problem is not the PHP version; the problem is that you're buffering unlimited amounts of data. Check your configuration and make sure ob_get_level() returns 0. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
On 05/01/2012 06:39 AM, Paul Reinheimer wrote:
Hi Larry,
Fascinating. I even verified the md5sum of the file I got on the other end
just to be sure. I'll hold off on the blog post then. :-) I look forward
to your test setup.
The server in question is still on PHP 5.2.13
Script:
?php
ini_set('memory_limit', '8M');
$name = uniqid() . .zip;
header('Content-type: application/zip');
header(Content-Disposition: attachment; filename=\$name\);
readfile('../../filestorage/4f9e9e3b9bcff.zip');
File Information:
[user@host public]$ ls -alh ../../filestorage/4f9e9e3b9bcff.zip
-rw-r--r-- 1 apache apache 27M Apr 30 10:14
../../filestorage/4f9e9e3b9bcff.zip
Error:
[Tue May 01 09:30:48 2012] [error] [client 198.136.162.2] PHP Fatal
error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 27617281 bytes) in
/home/lots/of/path.org/stuff/public/rf822.php on line 6
I'll try something newer, but I wanted to prove myself not crazy and
do it on the server in question first.
That's odd, because PHP 5.2 has identical code in this respect. Wez
committed these changes in 2002:
https://github.com/php/php-src/commit/a662f012bba5a6fdc50533673f3fff47bf9af219#diff-5
So it has been like this for quite a while. Does that server have
implicit unlimited output buffering turned on in your ini file?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
On 05/01/2012 07:27 AM, Rasmus Lerdorf wrote:
On 05/01/2012 06:39 AM, Paul Reinheimer wrote:
Hi Larry,
Fascinating. I even verified the md5sum of the file I got on the other end
just to be sure. I'll hold off on the blog post then. :-) I look forward
to your test setup.
The server in question is still on PHP 5.2.13
Script:
?php
ini_set('memory_limit', '8M');
$name = uniqid() . .zip;
header('Content-type: application/zip');
header(Content-Disposition: attachment; filename=\$name\);
readfile('../../filestorage/4f9e9e3b9bcff.zip');
File Information:
[user@host public]$ ls -alh ../../filestorage/4f9e9e3b9bcff.zip
-rw-r--r-- 1 apache apache 27M Apr 30 10:14
../../filestorage/4f9e9e3b9bcff.zip
Error:
[Tue May 01 09:30:48 2012] [error] [client 198.136.162.2] PHP Fatal
error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 27617281 bytes) in
/home/lots/of/path.org/stuff/public/rf822.php on line 6
I'll try something newer, but I wanted to prove myself not crazy and
do it on the server in question first.
That's odd, because PHP 5.2 has identical code in this respect. Wez
committed these changes in 2002:
https://github.com/php/php-src/commit/a662f012bba5a6fdc50533673f3fff47bf9af219#diff-5
So it has been like this for quite a while. Does that server have
implicit unlimited output buffering turned on in your ini file?
And actually, that patch just made it use streams. Even before the
internal streams API the function worked the same way. In PHP 4.2 it
used php_passthru_fd which looked like this:
https://github.com/php/php-src/blob/PHP-4.2.0/ext/standard/file.c#L1526
Sascha added the mmap implementation we still use today in 1999:
https://github.com/php/php-src/commit/dda0b783df7d849df01fa831febbc1e34b5b8dd3
But even prior to that readfile would still buffer in 8k chunks. The PHP
2.0.1 implementation (very scary to look at code I wrote 17 or 18 years
ago):
/*
* Read a file and write the ouput to stdout
*/
void ReadFile(void) {
Stack *s;
char buf[8192],temp[8];
FILE *fp;
int b,i, size;
s = Pop();
if(!s) {
Error(Stack error in ReadFile);
return;
}
if(!*(s-strval)) {
Push(-1,LNUMBER);
return;
}
#if DEBUG
Debug(Opening [%s]\n,s-strval);
#endif
StripSlashes(s-strval);
#if PHP_SAFE_MODE
if(!CheckUid(s-strval,1)) {
Error(SAFE MODE Restriction in effect. Invalid owner
of file to be read.);
Push(-1,LNUMBER);
return;
}
#endif
fp = fopen(s-strval,r);
if(!fp) {
Error(ReadFile(\%s\) - %s,s-strval,strerror(errno));
Push(-1,LNUMBER);
return;
}
size= 0;
php_header(0,NULL);
while((b = fread(buf, 1, sizeof(buf), fp)) 0) {
for(i = 0; i b; i++)
PUTC(buf [i]);
size += b ;
}
fclose(fp);
sprintf(temp,%d,size);
Push(temp,LNUMBER);
}
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi All, Unfortunately, you've ignored Uwe's e-mail... The problem is not the PHP version; the problem is that you're buffering unlimited amounts of data. Check your configuration and make sure ob_get_level() returns 0. My apologies in the delay, ob_get_level() returns 1, good catch. phpinfo() reports output_buffering as 4096 Does this push what I'm getting into expected behaviour? paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Vote change for empty() RFC
Hi internals! As per Pierres request I'm posting a new voting thread for my empty() RFC. During discussions on IRC it turned out that most people would prefer to allow expressions for empty(), but not for isset(), that's why the vote now has three options: * Both empty() and isset() should allow expressions * Only empty() should allow them * None of them should accept expressions https://wiki.php.net/rfc/empty_isset_exprs#vote Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
* None of them should accept expressions just to be clear, this means keeping the current behavior as is. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] readfile() memory usage
On 5/1/12 10:01 AM, Paul Reinheimer wrote: Hi All, Unfortunately, you've ignored Uwe's e-mail... The problem is not the PHP version; the problem is that you're buffering unlimited amounts of data. Check your configuration and make sure ob_get_level() returns 0. My apologies in the delay, ob_get_level() returns 1, good catch. phpinfo() reports output_buffering as 4096 Does this push what I'm getting into expected behaviour? paul 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. --Larry Garfield -- 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 Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov nikita@googlemail.comwrote: On Mon, Apr 30, 2012 at 9:50 AM, Patrick ALLAERT patrickalla...@php.net wrote: Hi, 2012/4/12 Nikita Popov nikita@googlemail.com: PS: I added isset() too, to address the consistency concerns mentioned on IRC. I would have voted +1 if it didn't contain the isset() change. None of the examples used in the isset_with_expr.phpt test seems logic to me. Care to explain the consistency concerns here? The concerns came from laruence, so maybe he could drop a comment here :) Basically, empty() and isset() are very similar in their nature, so changing only one of them might seem inconsistent. Personally I don't see much use in allowing expressions in isset(). People being confused by empty(trim($_GET['foo'])) not working is quite common, but I've never heard of somebody trying to use isset() on a function call. The name already makes clear that it's intended for use on variables. albeit I'm not laruence, but I also supported the idea to keep consistency across the allowed params of empty and isset. here is my reasoning: - both isset and empty are language constructs, which many people use almost interchangeability, changing one of them in a way that the same expression works with one of them, but blows up with a parse error seems wrong to me. - maybe you think that isset doesn't really make sense with expressions, but don't forget that this patch would also allow constants to be used with empty/isset, and imo isset(some_constant); would be useful and maybe more straightforward for the people new to the language. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
Hi, On Tue, May 1, 2012 at 18:43, Ferenc Kovacs tyr...@gmail.com wrote: albeit I'm not laruence, but I also supported the idea to keep consistency across the allowed params of empty and isset. here is my reasoning: - both isset and empty are language constructs, which many people use almost interchangeability, changing one of them in a way that the same expression works with one of them, but blows up with a parse error seems wrong to me. - maybe you think that isset doesn't really make sense with expressions, but don't forget that this patch would also allow constants to be used with empty/isset, and imo isset(some_constant); would be useful and maybe more straightforward for the people new to the language. So isset(UNDEFINEDCONSTANT) will be isset(UNDEFINEDCONSTANT) which will/should 1) yield a notice, which is unnexpected for isset 2) return true, which is also unexpected. I don't see much point in that. Best regards, -- Etienne Kneuss http://www.colder.ch -- 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()
2012/5/1 Ferenc Kovacs tyr...@gmail.com: On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov nikita@googlemail.comwrote: - both isset and empty are language constructs, which many people use almost interchangeability, changing one of them in a way that the same expression works with one of them, but blows up with a parse error seems wrong to me. I wish that more wrong usages could blow up with parse errors way before waiting for the incorrect line to be run. While there is some valid use cases for empty() I see none for isset(), it must remain a targeted and specific construct IMHO. - maybe you think that isset doesn't really make sense with expressions, exact :) but don't forget that this patch would also allow constants to be used with empty/isset. That is not a very good think IMO. For the same reason: this patch would also allow writing: empty( false ) or empty( null ) which are both clueless. The fact that this patch would now allow syntactically doubtful things doesn't mean they should be encouraged nor propagated to isset(). Cheers, Patrick -- 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 Thu, Apr 26, 2012 at 3:45 AM, C.Koy can5...@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();
$f = 'IJK';
# causes Fatal error: Call to undefined function IJK()
$f();
In contrast, if you set the locale for LC_CTYPE on the command line, the
bug doesn't arise at all because the compilation and execution phases both
use the same locale.
Could this be a clue for how to fix it for those as well?
Function names are generally resolved at compile time (dynamic function
names are resolved at run time, which is why the bug surfaces for them),
before the call to setlocale in the script has been executed. Class name
resolution is put off until execution time for autoloading and possibly
other purposes. Converting class names to lowercase at compile time may
work. A quick glance at the source shows that class_name,
fully_qualified_class_name and class_name_reference all depend on
namespace_name, which is the rule that is responsible for the parsing of
the class name.
namespace_name:
T_STRING { $$ = $1; }
| namespace_name T_NS_SEPARATOR T_STRING {
zend_do_build_namespace_name($$, $1, $3 TSRMLS_CC); }
;
However, static_scalar is also dependent on namespace_name, and I don't
believe that symbol should be made case-insensitive. Creating an additional
symbol for case-independency would allow a more targeted approach. The
various class symbols would then rely on this new symbol, rather than
namespace_name.
lc_namespace_name:
T_STRING { zend_str_tolower($1); $$ = $1; }
| lc_namespace_name T_NS_SEPARATOR T_STRING { zend_str_tolower($3);
zend_do_build_namespace_name($$, $1, $3 TSRMLS_CC); }
;
Converting class names to lower case early may have additional
consequences. It may affect class names in error messages, for example (I
didn't dig deep enough to determine this). __CLASS__ should be unaffected
(when defining a class, the class name is parsed as a T_STRING; the value
for __CLASS__ comes from this symbol). It also won't resolve the bug for
dynamic names. I suspect that altering variable_class_name and
dynamic_class_name_reference in a manner described previously (use a custom
lowercase conversion or temporarily switch locale) to convert the name
would resolve the bug in the dynamic case for class names. Changing a
number of the production rules for function_call in a similar manner should
resolve the bug for dynamic function call. Again, there will likely be
unintended consequences. Alternatively, updating
zend_do_begin_dynamic_function_call() and zend_do_fetch_class() to use
custom conversion should resolve the bug in the dynamic case.
I like the idea of using the system default locale for name conversion
(making name resolution independent of the current locale), but am
concerned that it will make name lookup slow. Instead, a second set of
locale-independent, unicode-aware conversion functions (basically, iliaa's
original solution, but Unicode compatible) to be used for identifiers would
make name resolution independent of the current locale. Any time an
identifiers needs to be converted, it would use one of these functions. As
a run-time optimization, non-dynamic class names could use the system
locale conversion, but that would be a separate thing from resolving this
bug.
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On Tue, May 1, 2012 at 11:11 AM, Galen Wright-Watson ww.ga...@gmail.comwrote: [...] Instead, a second set of locale-independent, unicode-aware conversion functions (basically, iliaa's original solution, but Unicode compatible) to be used for identifiers would make name resolution independent of the current locale. [...] I believe all these functions would need to do is use tolower, rather than tolower_l. So, perhaps the new functions should get the old names, and the old functions should get _l appended to their names.
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Tue, May 1, 2012 at 7:24 PM, Patrick ALLAERT patrickalla...@php.netwrote: 2012/5/1 Ferenc Kovacs tyr...@gmail.com: On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov nikita@googlemail.com wrote: - both isset and empty are language constructs, which many people use almost interchangeability, changing one of them in a way that the same expression works with one of them, but blows up with a parse error seems wrong to me. I wish that more wrong usages could blow up with parse errors way before waiting for the incorrect line to be run. One could argue that then you should pick a compiled language. While there is some valid use cases for empty() I see none for isset(), it must remain a targeted and specific construct IMHO. I agree that there is less valid use-cases, but I feel that keeping the two method consistent about this is more important. - maybe you think that isset doesn't really make sense with expressions, exact :) but don't forget that this patch would also allow constants to be used with empty/isset. That is not a very good think IMO. For the same reason: this patch would also allow writing: empty( false ) or empty( null ) which are both clueless. how is that different than for example writing is_null(null) ? The fact that this patch would now allow syntactically doubtful things doesn't mean they should be encouraged nor propagated to isset(). we are already have that all over the place, I don't think that this particular patch will change anything about that. could you elaborate on this part a little bit? I mean you can write stupid code right now ($null=null;isset($null); instead of isset(null);), I can't see how would this patch worsen the situation. If anything, the silly code could be understood easier, as you wouldn't need to debug the value of the $null variable passed in. So I think that 1, we already too late to prevent that kind of code 2. even if we could, I don't think that the currently discussed patch would really encourage that kind of code 3, there are/could be valid use-cases for isset 4, isset and empty should work the same way in regards of the argument parsing. ofc. this is only my opinion, if I am the minority here, then it is fine too, I just wanted to explain what was the reasoning behind that discussion. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] readfile() memory usage
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. thanks paul -- 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()
So isset(UNDEFINEDCONSTANT) will be isset(UNDEFINEDCONSTANT) which will/should 1) yield a notice, which is unnexpected for isset 2) return true, which is also unexpected. I don't see much point in that. yep, and if we allow expressions then it is the expected behavior, but you are right that this is will change the current standard that isset/empty can't raise a notice. but this isn't specific to isset, empty will also follow the same pattern. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: Bug/Req:#61422#39003 enble Type Hint autoloading
Hi everyone,
On 05/01/2012 03:25 PM, Laruence wrote:
if you pass a right instance of class to a function , how can that
class not be loaded already?
for example:
function foo(Foo_Bar $a) {
}
how can you pass a Foo_Bar instance to function foo without
Foo_Bar class already defined?
Because Foo_Bar could be *defined* under a different name, say,
Foo_Blah. Then, as soon as someone needed Foo_Bar, we would use
class_alias to add an alias. That is, as soon as someone tried using
Foo_Bar it would turn out that Foo_Bar and Foo_Blah are the same class
and all Foo_Blah objects are *also* Foo_Bar objects and everything is
cool. Therefore foo(new Foo_Blah()) would work (if there was autoload).
Please see the demo I provided at https://bugs.php.net/bug.php?id=61422
Then again, at least it's consistent with instanceof. Where calling
autoload by default is probably indeed unacceptable.
This is complicated.
--
Best regards,
Danko Alexeyev,
VeryPositive
+371 2648 3953
da...@very.lv
Skype: d.alexeyev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug/Req:#61422#39003 enble Type Hint autoloading
Hi! Because Foo_Bar could be *defined* under a different name, say, Foo_Blah. Then, as soon as someone needed Foo_Bar, we would use class_alias to add an alias. That is, as soon as someone tried using class_alias is a dirty hack. instanceof implies that the object is an instance of specific class. If the class is not loaded, no object can be an instance of it. So no autoloading is necessary. Foo_Bar it would turn out that Foo_Bar and Foo_Blah are the same class and all Foo_Blah objects are *also* Foo_Bar objects and everything is cool. Therefore foo(new Foo_Blah()) would work (if there was autoload). Please see the demo I provided at https://bugs.php.net/bug.php?id=61422 I do not see how anything good can come out of encouraging stuff like this. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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()
Sent from my iPhone 在 2012-5-2，3:52，Ferenc Kovacs tyr...@gmail.com 写道： So isset(UNDEFINEDCONSTANT) will be isset(UNDEFINEDCONSTANT) which will/should 1) yield a notice, which is unnexpected for isset 2) return true, which is also unexpected. I don't see much point in that. yep, and if we allow expressions then it is the expected behavior, but you are right that this is will change the current standard that isset/empty can't raise a notice. but this isn't specific to isset, empty will also follow the same pattern. This is really a issue . Thanks -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] how to instantiate new object
Hello, I was wondering how to create a new object from a function call? By this I mean if I call foo() from a script, that should return a new instance of an object. If I call foo() again, it should be a new instance of an object as well. I haven't been able to find any good examples from the code I've been reading. Does anyone know of a good place to find an example? thanks
[PHP-DEV] Re: how to instantiate new object
On Tue, May 1, 2012 at 8:46 PM, Yader Hernandez yader.hernan...@gmail.comwrote: Hello, I was wondering how to create a new object from a function call? By this I mean if I call foo() from a script, that should return a new instance of an object. If I call foo() again, it should be a new instance of an object as well. I haven't been able to find any good examples from the code I've been reading. Does anyone know of a good place to find an example? thanks To be a little clearer I mean that in my extension, I can call my custom object. So any calls from a script will be able to do $o = new Foo(). I registered my struct in zend_objects_store_put, so I understand how the instantiate is happening. But now I'm implementing a ZEND_METHOD that requires a new instance of Foo and I've been stuck for a few days trying to find a nice clean example. I was wondering if someone knew of a good place look into? thanks
Re: [PHP-DEV] Re: how to instantiate new object
On Wed, May 2, 2012 at 1:16 PM, Yader Hernandez yader.hernan...@gmail.com wrote: On Tue, May 1, 2012 at 8:46 PM, Yader Hernandez yader.hernan...@gmail.comwrote: Hello, I was wondering how to create a new object from a function call? By this I mean if I call foo() from a script, that should return a new instance of an object. If I call foo() again, it should be a new instance of an object as well. I haven't been able to find any good examples from the code I've been reading. Hi: MAKE_STD_ZVAL(instance); object_init(instance , class_entry_ce); and if you want to call the contructor, you have to call it explicitly. see: http://lxr.php.net/opengrok/xref/PECL/yaf/views/simple.c#216 thanks Does anyone know of a good place to find an example? thanks To be a little clearer I mean that in my extension, I can call my custom object. So any calls from a script will be able to do $o = new Foo(). I registered my struct in zend_objects_store_put, so I understand how the instantiate is happening. But now I'm implementing a ZEND_METHOD that requires a new instance of Foo and I've been stuck for a few days trying to find a nice clean example. I was wondering if someone knew of a good place look into? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: how to instantiate new object
On Wed, May 2, 2012 at 1:27 PM, Laruence larue...@php.net wrote: On Wed, May 2, 2012 at 1:16 PM, Yader Hernandez yader.hernan...@gmail.com wrote: On Tue, May 1, 2012 at 8:46 PM, Yader Hernandez yader.hernan...@gmail.comwrote: Hello, I was wondering how to create a new object from a function call? By this I mean if I call foo() from a script, that should return a new instance of an object. If I call foo() again, it should be a new instance of an object as well. I haven't been able to find any good examples from the code I've been reading. Hi: MAKE_STD_ZVAL(instance); object_init(instance , class_entry_ce); typo, should be object_init_ex. thanks and if you want to call the contructor, you have to call it explicitly. see: http://lxr.php.net/opengrok/xref/PECL/yaf/views/simple.c#216 thanks Does anyone know of a good place to find an example? thanks To be a little clearer I mean that in my extension, I can call my custom object. So any calls from a script will be able to do $o = new Foo(). I registered my struct in zend_objects_store_put, so I understand how the instantiate is happening. But now I'm implementing a ZEND_METHOD that requires a new instance of Foo and I've been stuck for a few days trying to find a nice clean example. I was wondering if someone knew of a good place look into? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: how to instantiate new object
BTW: you should write to pecl-dev ML for such questions. thanks On Wed, May 2, 2012 at 1:28 PM, Laruence larue...@php.net wrote: On Wed, May 2, 2012 at 1:27 PM, Laruence larue...@php.net wrote: On Wed, May 2, 2012 at 1:16 PM, Yader Hernandez yader.hernan...@gmail.com wrote: On Tue, May 1, 2012 at 8:46 PM, Yader Hernandez yader.hernan...@gmail.comwrote: Hello, I was wondering how to create a new object from a function call? By this I mean if I call foo() from a script, that should return a new instance of an object. If I call foo() again, it should be a new instance of an object as well. I haven't been able to find any good examples from the code I've been reading. Hi: MAKE_STD_ZVAL(instance); object_init(instance , class_entry_ce); typo, should be object_init_ex. thanks and if you want to call the contructor, you have to call it explicitly. see: http://lxr.php.net/opengrok/xref/PECL/yaf/views/simple.c#216 thanks Does anyone know of a good place to find an example? thanks To be a little clearer I mean that in my extension, I can call my custom object. So any calls from a script will be able to do $o = new Foo(). I registered my struct in zend_objects_store_put, so I understand how the instantiate is happening. But now I'm implementing a ZEND_METHOD that requires a new instance of Foo and I've been stuck for a few days trying to find a nice clean example. I was wondering if someone knew of a good place look into? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
