Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken
Hi! So what is the resolution for this? Should we roll back the fix, implement the new one and have one more RC, do something else? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On Tue, Sep 9, 2014 at 3:07 AM, Andrea Faulds wrote:
>
> On 8 Sep 2014, at 23:58, Adam Harvey wrote:
>
>> +1 on ?? — there's precedent for it, and it means we don't have to
>> explain why the shorthand form of an operator behaves differently to
>> the long form, which is just going to confuse users.
>
> FWIW, it already behaves differently:
>
> oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; }
> $x = foo() ?: false;'
> foo
> oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; }
> $x = foo() ? foo() : false;'
> foo
> foo
That's arguable ... I'd say that ($x = foo()) ? $x : false; is the
logical equivalent of your first example.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On 8 September 2014 17:07, Andrea Faulds wrote:
>
> On 8 Sep 2014, at 23:58, Adam Harvey wrote:
>
>> +1 on ?? — there's precedent for it, and it means we don't have to
>> explain why the shorthand form of an operator behaves differently to
>> the long form, which is just going to confuse users.
>
> FWIW, it already behaves differently:
>
> oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; }
> $x = foo() ?: false;'
> foo
> oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; }
> $x = foo() ? foo() : false;'
> foo
> foo
You could argue whether that's unexpected behaviour or not — there is
only one foo() call in the shorthand version, after all, so it makes
intuitive sense that foo() would only be called once.
Regardless of how you feel about that, though, I don't think
increasing the amount of inconsistency between two versions of the
same operator (forget the implementation; that's how it's documented
and how it's perceived) is a good idea.
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On 8 Sep 2014, at 23:58, Adam Harvey wrote:
> +1 on ?? — there's precedent for it, and it means we don't have to
> explain why the shorthand form of an operator behaves differently to
> the long form, which is just going to confuse users.
FWIW, it already behaves differently:
oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; }
$x = foo() ?: false;'
foo
oa-res-27-90:~ ajf$ php -r 'function foo() { echo "foo\n"; return true; }
$x = foo() ? foo() : false;'
foo
foo
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On 8 September 2014 07:56, Christoph Becker wrote: > Am 08.09.2014 15:58, schrieb Andrea Faulds: >> We could add such an operator, perhaps with the ?? syntax. However, I >> don’t really like the idea. It’s too similar to ?: so I don’t think >> it’d be accepted, and even if it was, I’m not sure we really need >> another operator. I’d much rather just make ?: do what, IMO, is the >> right thing and what it always should have done. > > I'd rather had a shortcut for the following: > > isset($_GET['foo']) ? $_GET['foo'] : BAR Agreed. That's what ifsetor requests have generally boiled down to over the years, so it seems to be what the masses want. It's what _I_ want, anyway. :) > Of course, it is not possible to change the ?: operator to work this way > for BC reasons, but a new operator such as ?? might make sense. +1 on ?? — there's precedent for it, and it means we don't have to explain why the shorthand form of an operator behaves differently to the long form, which is just going to confuse users. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
Am 08.09.2014 15:58, schrieb Andrea Faulds: > On 8 Sep 2014, at 13:04, Shashank Kumar > wrote: > >> Rather than giving a new meaning to an old operator why not have a >> different operator for this? .NET has a 'null coalescing' operator >> for the same purpose which works out quite well in the given >> situation and is non-ambiguous as well. >> http://msdn.microsoft.com/en-us/library/ms173224.aspx > > We could add such an operator, perhaps with the ?? syntax. However, I > don’t really like the idea. It’s too similar to ?: so I don’t think > it’d be accepted, and even if it was, I’m not sure we really need > another operator. I’d much rather just make ?: do what, IMO, is the > right thing and what it always should have done. I'd rather had a shortcut for the following: isset($_GET['foo']) ? $_GET['foo'] : BAR What the "Implicit isset() in Shorthand Ternary Operator" RFC proposes is not equivalent (despite the RFC's name), consider e.g. $_GET['foo'] === "" $_GET['foo'] === "0" Of course, it is not possible to change the ?: operator to work this way for BC reasons, but a new operator such as ?? might make sense. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On 8 Sep 2014, at 09:06, Michael Wallner wrote: > On 07/09/14 14:25, Andrea Faulds wrote: >> >> On 7 Sep 2014, at 13:22, Sherif Ramadan >> wrote: >> >>> I've played around with this branch for a bit and seems reasonable, >>> passes the tests, and doesn't seem to have any serious >>> issues/memories leaks AFAICT. >> >> There’s actually a quite serious issue just now, which is that it >> evaluates the first operand twice if it’s not empty. This is because >> $a ?: $b is expanded to empty($a) ? $b : $a, such that if you did >> something which mutates state in there, it’d happen twice. This is >> obviously not good, and I’m going to figure out how to fix this. >> > > This could very well be the reason why it is like it is today. I doubt it, it’s possible to avoid double-evalution, and I don’t think it’s terribly difficult. I just did things the easy way and it turns out that has problems. On 8 Sep 2014, at 13:04, Shashank Kumar wrote: > Rather than giving a new meaning to an old operator why not have a different > operator for this? > .NET has a 'null coalescing' operator for the same purpose which works out > quite well in the given situation > and is non-ambiguous as well. > http://msdn.microsoft.com/en-us/library/ms173224.aspx We could add such an operator, perhaps with the ?? syntax. However, I don’t really like the idea. It’s too similar to ?: so I don’t think it’d be accepted, and even if it was, I’m not sure we really need another operator. I’d much rather just make ?: do what, IMO, is the right thing and what it always should have done. On 8 Sep 2014, at 08:58, Simon Schick wrote: > I feel more like Sherif Ramadan. Even so I've quite often been in the same > situation, I don't think it's a good solution to change something like that, > just for the shorthand-operator. > > I think, the notice is really valuable when accessing the value and doing > something with it - like myFunction($_GET['not_set']), but if you're just > checking for the existence, I, too, think it is more annoying. My way was to > suppress it by adding the silence-operator ;) > > I always used like: > @$_GET['mykey'] ?: ”” The silence operator is bad for three reasons. First, it’s very slow, having a significant performance impact. Second, @ silences not only innocuous E_NOTICEs, but *all* errors, even very serious ones. That’s not good. The third is that it interacts with some error handlers badly, or so I’ve heard. > I can't come up with a good mid-way right now, but I don't think it's a good > way to change this ONLY for the short-hand operator. Actually, there is a case for doing it for $a ?: $b and not $a ? $a : $b, in that it could avoid double evaluation (you’d be able to do foo()[0] ?: $bar and foo() would only be called once) and because with the full-length ternary operator, it wouldn’t really help you much: $_GET[‘foo’] ? $_GET[‘foo’] : ‘blah’ isn’t much shorter than the version with explicit isset. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
Hi Andrea Rather than giving a new meaning to an old operator why not have a different operator for this? .NET has a 'null coalescing' operator for the same purpose which works out quite well in the given situation and is non-ambiguous as well. http://msdn.microsoft.com/en-us/library/ms173224.aspx
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On Mon, Sep 8, 2014 at 4:06 AM, Michael Wallner wrote: > On 07/09/14 14:25, Andrea Faulds wrote: > > > > > There’s actually a quite serious issue just now, which is that it > > evaluates the first operand twice if it’s not empty. This is because > > $a ?: $b is expanded to empty($a) ? $b : $a, such that if you did > > something which mutates state in there, it’d happen twice. This is > > obviously not good, and I’m going to figure out how to fix this. > > > > This could very well be the reason why it is like it is today. > > I agree. The more I think about, the more this seems weird. What if I explicitly want to use ternary to check isset() and not empty?
Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan wrote: > Actually, we shouldn't be doing that all. We should simply just overwrite > the header. It wouldn't make much sense to set two headers with the same > cookie name when we can just overwrite it. > > > that would be a bigger BC break, and without a warning, those people affected by the change will have a harder time figuring out what went wrong. and as was discussed both in the PR and the bugreport the rfc discourages but doesn't prohibit this behavior, so making it impossible for the userland to do it would be a bit of an arbitrary restriction. maybe we could do something like introducing a new $overwrite = true option to the function signature, but setcookie already has 7 arguments, so probably isn't a great idea. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
On 08/09/14 09:15, Sherif Ramadan wrote: > Actually, we shouldn't be doing that all. We should simply just overwrite > the header. It wouldn't make much sense to set two headers with the same > cookie name when we can just overwrite it. Maybe, but the SAPI_HEADER_* only look for the header name, not its contents. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On 07/09/14 14:25, Andrea Faulds wrote: > > On 7 Sep 2014, at 13:22, Sherif Ramadan > wrote: > >> I've played around with this branch for a bit and seems reasonable, >> passes the tests, and doesn't seem to have any serious >> issues/memories leaks AFAICT. > > There’s actually a quite serious issue just now, which is that it > evaluates the first operand twice if it’s not empty. This is because > $a ?: $b is expanded to empty($a) ? $b : $a, such that if you did > something which mutates state in there, it’d happen twice. This is > obviously not good, and I’m going to figure out how to fix this. > This could very well be the reason why it is like it is today. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
Hi, Andrea I feel more like Sherif Ramadan. Even so I've quite often been in the same situation, I don't think it's a good solution to change something like that, just for the shorthand-operator. I think, the notice is really valuable when accessing the value and doing something with it - like myFunction($_GET['not_set']), but if you're just checking for the existence, I, too, think it is more annoying. My way was to suppress it by adding the silence-operator ;) I always used like: @$_GET['mykey'] ?: ”” I can't come up with a good mid-way right now, but I don't think it's a good way to change this ONLY for the short-hand operator. Bye, Simon On Sat, Sep 6, 2014 at 2:02 AM, Andrea Faulds wrote: > Good evening, > > I’ve written an RFC and working patch which attempt to add this feature > which has been often requested: https://wiki.php.net/rfc/isset_ternary > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Memory corruptions related to AST patch
Hi Nikita,
On weekend I ran PHP test suite with valgrind and opcache.
I noticed few new tests failures, that most probably introduced by AST
patch.
Bug #21820 ("$arr['foo']" generates bogus E_NOTICE, should be E_PARSE)
[tests/lang/bug21820.phpt]
Bug #66286: Incorrect object comparison with inheritance
[Zend/tests/bug66286.phpt]
unbraced complex variable replacement test (heredoc)
[Zend/tests/heredoc_005.phpt]
isset() can be used on dereferences of temporary expressions
[Zend/tests/varSyntax/issetOnTemp.phpt]
I suppose they indicate two different problems.
One of them indicates that some zvals became a subject for GC, however they
won't before. This may be fixed in opcache, but it's better to understand
what was changed.
Please take a look.
Thanks. Dmitry.
Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
Actually, we shouldn't be doing that all. We should simply just overwrite the header. It wouldn't make much sense to set two headers with the same cookie name when we can just overwrite it. On Mon, Sep 8, 2014 at 2:50 AM, Tjerk Meesters wrote: > Hi! > > > On Sat, Sep 6, 2014 at 5:38 AM, Florian Margaine > wrote: > > > Hi, > > > > This is a minor BC break, but still a BC break, so worth discussing on > this > > ML. > > > > When a second setcookie() is done with the same name, a warning is > emitted, > > because the ietf rfc 6265 says it *should* only send one Set-Cookie > header > > per name. > > > > This is fine when display_errors is set to off. When it's set to on, the > > warning prevents the header from being added because "headers already > sent" > > (which is the minor BC break, as current PHP just sends 2 Set-Cookie > > headers with the same name). > > > > Yeah, it would prevent any header() or setcookie() following that warning > from taking place. > > How about delaying that warning until the headers are sent? > > > > > > So, should it be merged? What should be done to comply with the ietf rfc > > 6265? > > > > PR: https://github.com/php/php-src/pull/795/ > > PHP issue: https://bugs.php.net/bug.php?id=67736 > > > > Regards, > > > > *Florian Margaine* > > > > > > -- > -- > Tjerk >
[PHP-DEV] Re: zend_mm_small_size_to_bit
Hi Matt,
You are right about zend_mm_small_size_to_bit(). It's result must be
undefined for 0 and corresponding part of non-GCC version may be removed as
well. I'll do it.
Thanks. Dmitry.
On Fri, Sep 5, 2014 at 8:00 PM, Matt Wilmas wrote:
> Hi Dmitry, all,
>
> I was looking through a few parts of the new MM last week (cool, thanks! I
> will try soon on my Windows XP), and wasn't sure about the function in the
> subject...
>
> This:
>
> /* higher set bit number (0->0, 1->1, 2->2, 4->3, 8->4, 127->7, 128->8
> etc) */
> static zend_always_inline int zend_mm_small_size_to_bit(int size)
> {
> #if defined(__GNUC__)
> return (__builtin_clz(size) ^ 0x1f) + 1;
>
> Will never return 0, right? (Against the comment...) That's OK I guess
> since, for now, it's only called with size >= 8.
>
> But in that case, this can be removed from the non-GCC version:
>
> if (size == 0) return 0;
>
> Shouldn't have just one version able to return 0? :-/ Unless I'm missing
> something! Let me know...
>
>
> Thanks,
> Matt
>
