Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Mon, Apr 30, 2012 at 3:50 PM, 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. Hi: isset and empty are generally think as a pair, and the both even share one ZEND_OP: ZEND_ISSET_ISEMPTY_VAR so I think if you want to change empty, you should also change isset. thanks Care to explain the consistency concerns here? Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] [RFC] Allow non-variable arguments to empty() and isset()
hi, On Wed, May 2, 2012 at 10:46 AM, Laruence larue...@php.net wrote: so I think if you want to change empty, you should also change isset. An expression is not set per se. isset goals, by design, from the very 1st day, is to test the existence of a variable and a variable only. empty() on the other hand, tests if something is empty, and only if it is empty. The result of an expression can be empty. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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, 2012-05-02 at 13:27 +0800, Laruence 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); 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 This doesn't seem to run the ctor. Full example is ZEND_METHOD(reflection_class, newInstance) http://lxr.php.net/opengrok/xref/PHP_5_4/ext/reflection/php_reflection.c#4092 johannes -- 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 at 11:10 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, May 2, 2012 at 10:46 AM, Laruence larue...@php.net wrote: so I think if you want to change empty, you should also change isset. An expression is not set per se. isset goals, by design, from the very 1st day, is to test the existence of a variable and a variable only. Returns TRUE if var exists and has value other than NULL, FALSE otherwise. $foo=null; var_dump(isset($foo)); //prints bool(false) 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
hi, On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs tyr...@gmail.com wrote: $foo=null; var_dump(isset($foo)); //prints bool(false) No offset meant, but it is totally expected and well known, and as far as I remember documented too. Assigning NULL to a variable unsets it (so to say). 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. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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 at 11:43 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs tyr...@gmail.com wrote: $foo=null; var_dump(isset($foo)); //prints bool(false) No offset meant, lapsus :) s,offset,offense, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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()
Pierre, On Wed, May 2, 2012 at 5:43 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs tyr...@gmail.com wrote: $foo=null; var_dump(isset($foo)); //prints bool(false) No offset meant, but it is totally expected and well known, and as far as I remember documented too. Assigning NULL to a variable unsets it (so to say). Well, except that it doesn't unset it. It only fails isset(). The symbol still exists in the symbol table, and the zval is still allocated. That's one reason that isset() can return false, and array_key_exists() will return true. But right now there's no way to check if a symbol exists since isset returns falls for a null value in a symbol (and there's no other way to check it)... Not saying it should change, just that it's a corner case that's not accounted for in the API... I voted for the ability to use an expression for isset() as well, since I agree with Ferenc, it's a matter of consistency. Sure, the use-case for isset() is definitely weaker than for empty(), but at the same token they are definitely related... Anthony 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. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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] [RFC] Allow non-variable arguments to empty() and isset()
On Wed, May 2, 2012 at 11:43 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs tyr...@gmail.com wrote: $foo=null; var_dump(isset($foo)); //prints bool(false) No offset meant, but it is totally expected and well known, and as far as I remember documented too. Assigning NULL to a variable unsets it (so to say). sure, as I quoted the documentation here. I just wanted to emphasize, that isset not only checks if a variable is set or not, but also checks the value of the variable, which makes your argument (An expression is not set per se. isset goals, by design, from the very1st day, is to test the existence of a variable and a variable only.) much weaker. 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. yeah, but that wasn't my point, I was saying that an expression can also have a value of null, which can be checked by isset, so empty and isset isn't any different in that regard for expressions. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
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 ?
$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.
So, the bug also arises if a script started in 'tr_TR' env locale sets
its locale to 'en_US' at runtime.
[...]
I like the idea of using the system default locale for name conversion
(making name resolution independent of the current locale), but am
As I stated above, the locale the script was started in may not always
be 'en_US' or 'C'. (assuming that's what you mean by system default
locale)
By the way, I noticed a setlocale(LC_CTYPE, ) call in
php_module_startup()/main.c, but can't figure if it has any relevance to
this bug.
regards,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Trouble with zend_language_parser.y
Anyone have any help with this?
$1 of the first T_ISSET is matching against \n\t\tisset {... (... being the
rest of the set body through to the end of the script.
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Wednesday, April 25, 2012 10:41 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Trouble with zend_language_parser.y
I'm having some trouble setting up the re2c to allow the isset/unset. Here are
the definitions, I've added the two T_ISSET statements:
accessors:
accessor_function
accessor_function
accessor_function
accessor_function
| accessor_function
accessor_function
accessor_function
| accessor_function
accessor_function
| accessor_function
| /* Empty */
;
accessor_modifiers:
/* empty */
{ Z_LVAL($$.u.constant) =
CG(access_type); }
| non_empty_accessor_modifiers { $$ =
$1; }
;
non_empty_accessor_modifiers:
accessor_modifier
{ $$ = $1; }
| non_empty_accessor_modifiers accessor_modifier
{ Z_LVAL($$.u.constant) = zend_do_verify_access_types($1, $2); }
accessor_modifier:
T_PUBLIC
{ Z_LVAL($$.u.constant) = ZEND_ACC_PUBLIC; }
| T_PROTECTED
{ Z_LVAL($$.u.constant) = ZEND_ACC_PROTECTED; }
| T_PRIVATE
{ Z_LVAL($$.u.constant) = ZEND_ACC_PRIVATE; }
| T_STATIC
{ Z_LVAL($$.u.constant) = ZEND_ACC_STATIC; }
| T_FINAL
{ Z_LVAL($$.u.constant) = ZEND_ACC_FINAL; }
;
accessor_function:
T_ISSET
{ Z_LVAL($$.u.constant) =
ZEND_ACC_PUBLIC; zend_do_begin_accessor_declaration($1, CG(accessor_node),
$$, 0 TSRMLS_CC); }
'{'
inner_statement_list '}'
{
zend_do_end_accessor_declaration($1, CG(accessor_node), $$, $3 TSRMLS_CC); }
| T_ISSET
{ Z_LVAL($$.u.constant) =
ZEND_ACC_PUBLIC;
zend_do_begin_accessor_declaration($1, CG(accessor_node), $$, 0 TSRMLS_CC);
zend_do_end_accessor_declaration($1, CG(accessor_node), $$, NULL TSRMLS_CC);
}
';'
| accessor_modifiers is_reference T_STRING
{
zend_do_begin_accessor_declaration($3, CG(accessor_node), $1, $2.op_type
TSRMLS_CC); }
'{'
inner_statement_list '}'
{
zend_do_end_accessor_declaration($3, CG(accessor_node), $1, $5 TSRMLS_CC); }
| accessor_modifiers is_reference T_STRING
{
zend_do_begin_accessor_declaration($3, CG(accessor_node), $1, $2.op_type
TSRMLS_CC);
zend_do_end_accessor_declaration($3, CG(accessor_node), $1, NULL TSRMLS_CC);
}
';'
;
Here is the PHP it's trying to parse:
public $Hours {
get {
echo Getting Hours\r\n;
return $this-Seconds / 3600;
}
set { // The variable $value holds the incoming
value to be set
echo Setting Hours to
{$value}\r\n;
$this-Seconds = $value * 3600;
}
isset { return
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On Wed, May 2, 2012 at 5:23 AM, C.Koy can5...@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?
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.
So, the bug also arises if a script started in 'tr_TR' env locale sets its
locale to 'en_US' at runtime.
Yup.
$ LC_CTYPE=tr_TR php
?php
setlocale(LC_CTYPE, 'en_US');
class I {}
$i = new I;
^D
Fatal error: Class 'I' not found in - on line 4
Call Stack:
0.3740 630760 1. {main}() -:0
I should say that the Vulcan Logic Disassembler has been very helpful to me
in exploring this bug. Thank you, Derick Rethans and the rest of the VLD
team. If you haven't tried it, check it out.
[...]
I like the idea of using the system default locale for name conversion
(making name resolution independent of the current locale), but am
As I stated above, the locale the script was started in may not always be
'en_US' or 'C'. (assuming that's what you mean by system default locale)
That's indeed what I meant; basically, the locales specified in the
LC_CTYPE c. environment variables.
It shouldn't matter that the default locale isn't en_US or C, as long
as PHP always uses the same locale for identifiers both during compilation
and at run-time. Of course, it also makes a certain amount sense to
explicitly decide that PHP will use a specific locale for identifiers. I
avoided suggesting that route to avoid any issues about what locales will
be universally available.
By the way, I noticed a setlocale(LC_CTYPE, ) call in
php_module_startup()/main.c, but can't figure if it has any relevance to
this bug.
That would set the locale to whatever the platform uses natively. Without
the call, the locale would be POSIX/C, according to the POSIX doc (
http://pubs.opengroup.org/onlinepubs/009604499/functions/setlocale.html).
It doesn't seem terribly relevant to bug 18556, since all that matters
regarding the initial locale is that its lowercase conversion is different
from the locale that's used at run-time. If I had to guess why the locale
is set to the platform native, it's so that numeric, currency and date
formatting will be consistent with the rest of the system.
Re: [PHP-DEV] readfile() memory usage
On 05/01/2012 11:40 AM, Larry Garfield wrote: 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 Thanks for the sanity check, everyone. I've put together a blog post with my findings. If anyone wants to check it to make sure I am not saying anything grotesquely wrong before I posted it, that would be much appreciated. :-) It's set to world-commentable: https://docs.google.com/document/d/1qfe4OUc5lbuoSZFUh6NZYP-6pbaiquxnOFwN_oBccBI/edit --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()
hi Anthony, On Wed, May 2, 2012 at 1:37 PM, Anthony Ferrara ircmax...@gmail.com wrote: I voted for the ability to use an expression for isset() as well, since I agree with Ferenc, it's a matter of consistency. Sure, the use-case for isset() is definitely weaker than for empty(), No, it is not about consistency but goals and meaning. An expression is not set or unset. Anyway, that's not something we can argue about forever :-). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
