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 part
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
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 inheri
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 my
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 i
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, n
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 with
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, su
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
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/me
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 g
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
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:
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.
>
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 use
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://
16 matches
Mail list logo
