May be this overflow checks should be optional?
In old ages compilers for Wirth family languages had option to enable or
disable overflow checks.
If option is enabled we may throw an exception, if no - work as today.
Any user would be able to chose between compatibility and safety.
Thanks. Dmitry.
Simple majority between second and third options will win,
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 7:55 AM, Xinchen Hui wrote:
> On Fri, Sep 26, 2014 at 11:54 AM, Xinchen Hui wrote:
> > Hey:
> >
> >
> >
> > On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov wrote:
> >> I told it doesn't support s
On Fri, Sep 26, 2014 at 11:54 AM, Xinchen Hui wrote:
> Hey:
>
>
>
> On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov wrote:
>> I told it doesn't support strings and objects because it was designed this
>> way.
>> I don't know who and when did it.
>>
>> It's not complicated to change it in any way.
Hey:
On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov wrote:
> I told it doesn't support strings and objects because it was designed this
> way.
> I don't know who and when did it.
>
> It's not complicated to change it in any way.
> The question which way is better, and it's the reason of voting.
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.
It's not complicated to change it in any way.
The question which way is better, and it's the reason of voting.
I would prefer not to extend list() to support strings, but in case
"ena
On Thu, Sep 25, 2014 at 11:50 PM, Stas Malyshev
wrote:
> Hi!
>
> > It was on design. list() was intended to support plain arrays only.
>
> I'm not sure I'm getting this point - why list($a, $b) = $foo is not
> just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
> it work that
On 25 September 2014 22:50, Stas Malyshev wrote:
> Hi!
>
>> It was on design. list() was intended to support plain arrays only.
>
> I'm not sure I'm getting this point - why list($a, $b) = $foo is not
> just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
> it work that way?
>
Hi!
> It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 12:45 AM, Nikita Popov wrote:
> On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov
> wrote:
>
>> On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote:
>>
>>> disabling string handling would
FETCH_DIM_TMP_VAR is used especiualy for list().
It expects array, don't check for objects and strings.
It doesn't remove the operand and allow it's reuse in next opcode.
FETCH_DIM_R is used for list() only in some cases (when operand IS_VAR).
To work in list() context it has to keep operand not d
On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov wrote:
> On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote:
>
>> disabling string handling would allow make operation simpler and would
>> improve regular access to array elements.
>> We won't need to check for (opline->extended_value & ZEND_FETC
On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote:
> disabling string handling would allow make operation simpler and would
> improve regular access to array elements.
> We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
> in FETCH_DIM_R handler.
> However, it's going to
On 25.09.14 09:42, Dmitry Stogov wrote:
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Voted +1 for disabling.
I think string handling needs more thorough designing and planning for
edge case and such; i.e. the string handling alternative seems to rushed
to me
2014-09-25 9:42 GMT+02:00 Dmitry Stogov :
> Hi,
>
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>
> Thanks. Dmitry.
>
Hi,
I'm in favor of disabling for consistency as well, however, I wish a
warning would be emitted.
Not only it would tell me that I have a po
Hi everyone,
On 25 Sep 2014, at 17:27, Patrick ALLAERT wrote:
[...]
>
> I'm in favor of disabling for consistency as well, however, I wish a
> warning would be emitted.
Voted in favour of disabling as well but could easily live with the other
option as everything is better then leaving the inc
Andrea Faulds wrote (on 25/09/2014):
>> No bogus value ever gets to a function - it always gets INT_MAX on
>> > overflow. If INT_MAX is harmful for this function, this change
does not
>> > help as you could still pass INT_MAX and this change would not do
anything.
>>
> No it won't. Normally it
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a lot. :)
enabling s
Christian Stoller wrote (on 25/09/2014):
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September
25, 2014 12:31 PM
Sorry, I was talking about this bit:
Currently, switch always uses a "loose" comparison (==), so cannot
distinguish between "case 3" and "case 3.0". Occas
Hi,
On Thu, 2014-09-25 at 12:22 +0200, Florian Margaine wrote:
> Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
> https://github.com/krakjoe/php-src/compare/addressof
>
> I think it makes more sense than a new method on all objects. You could use
> it for any kind of value
Le 25 sept. 2014 12:54, "Pierre Joye" a écrit :
>
> On Thu, Sep 25, 2014 at 12:22 PM, Florian Margaine
wrote:
> > Hi,
> >
> > Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
> > https://github.com/krakjoe/php-src/compare/addressof
> >
> > I think it makes more sense than a
On Thu, Sep 25, 2014 at 12:22 PM, Florian Margaine wrote:
> Hi,
>
> Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
> https://github.com/krakjoe/php-src/compare/addressof
>
> I think it makes more sense than a new method on all objects. You could use
> it for any kind of val
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September
25, 2014 12:31 PM
>
> Sorry, I was talking about this bit:
>
>> Currently, switch always uses a "loose" comparison (==), so cannot
>> distinguish between "case 3" and "case 3.0". Occasionally, it would be
>> nice t
Christian Stoller wrote (on 25/09/2014):
Am I missing something equally obvious there? Or just, it doesn't
>interest people much as an idea?
Why should one add a new operator in that context if it is already
possible with assigments as expressions?
This makes the language more complex without g
Hi,
Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
https://github.com/krakjoe/php-src/compare/addressof
I think it makes more sense than a new method on all objects. You could use
it for any kind of value: scalar, resource, object. Building an array of
sockets, for example
Mit freundlichen Grüßen aus Paderborn
Christian Stoller
Softwareentwicklung
LEONEX Internet GmbH
Technologiepark 20
33100 Paderborn
Tel: 05251-14807-27
Fax: 05251-14807-30
HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter
-
On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds wrote:
>
> On 24 Sep 2014, at 20:39, Stas Malyshev wrote:
>
>>> I also wonder why we still need them. Doing what has been done with gmp
>>> for all resources would be a good move for 7.
>>
>> In general, I think we do not - IIRC everything resources
On 25 September 2014 09:21, Lester Caine wrote:
>
> 'This function returns a unique identifier for the object.'
> There is a mistaken view in some usage that that will be DIFFERENT for
> different versions of the same object.
Not sure who has that view. It's quite clearly documented, for the
life
Rowan Collins wrote (on 24/09/2014):
On 24/09/2014 22:33, Andrea Faulds wrote:
On 24 Sep 2014, at 22:17, Rowan Collins wrote:
Perhaps rather than a magic function or constant, though, the switch
statement could be extended with an "as" argument, which would store
the evaluated expression int
On 25/09/14 08:44, Leigh wrote:
> On 25 September 2014 08:40, Lester Caine wrote:
>> >
>> > Why would we need to build a hash of this object? It would provide
>> > nothing of use since we have a clean object key. Some people seem to
>> > think a hash will provide an indication that an object has c
On Thu, Sep 25, 2014 at 7:28 AM, Daniel Lowrey wrote:
> > FYI: I've tagged 5.6.1 and I had to revert the following commits for
> this:
> > 372844918a318ad712e16f9ec636682424a65403
> > f86b2193a483f56b0bd056570a0cdb57ebe66e2f
> > 30a73658c63a91c413305a4c4d49882fda4dab3e
> > 84a4041ba47e92e7a0ba039
On 25 September 2014 08:42, Dmitry Stogov wrote:
> Hi,
>
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>
> Thanks. Dmitry.
Since in the "should people be allowed to vote" thread, I said I think
people should explain their votes, here is my explanation :)
I am
Hi! I'm typing on my phone at the airport so apologies for the brevity and
lack of quoting from previous messages. I will summarize everything in
detail with commit references to clear up any confusion in the next couple
of days.
I believe that by applying the patch below to the 5.4 and 5.5 branch
On 25 September 2014 08:40, Lester Caine wrote:
>
> Why would we need to build a hash of this object? It would provide
> nothing of use since we have a clean object key. Some people seem to
> think a hash will provide an indication that an object has changed, but
> in reality that is also reliant
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Thanks. Dmitry.
On 25/09/14 06:19, Patrick Schaaf wrote:
> Am 24.09.2014 22:01 schrieb "Andrea Faulds" :
>> >
>> > Now, if we were to add actual object key support, that I might like. But
> if we’re going to keep with just integers and strings, I’d much prefer to
> just support __toString here. I think users are s
Hi!
> As you said, "5.4 is now supposed to be security-only" so I rather
> think we should revert to 5.4.32 code and have the upcoming fix only
> in 5.5+ (so in 5.5.18RC and 5.6.2RC)
OK, I'll revert it then to 5.4.32 state tomorrow. But the problem is
up-merging it - are there any fixes already c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 25/09/2014 09:00, Stas Malyshev a écrit :
> Hi!
Hi,
>> After a quick check
Too quick, I miss 84a4041 ;)
>> 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1 f86b219
>> and 3728449 are in 5.6.1RC1 only
>
> So, for 5.4 should we revert 6569db
Hi!
> I will review and report back on the 5.6.1 later today. I've checked with
> the horde folks and my recent uncommitted patch resolves any bugs (both old
> and new). I plan to commit this for 5.4 and 5.5 today and then subsequently
What is this new patch? Please note 5.4 is now supposed to be
Hi!
> After a quick check
>
> 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1
> f86b219 and 3728449 are in 5.6.1RC1 only
So, for 5.4 should we revert 6569db8 and 32be79d then? What about
upmerging to 5.5? What about f86b2193, should this be reverted too? I'm
feeling I don't understand what
39 matches
Mail list logo
