Re: [PHP-DEV] PDO: Disable emulated prepares by default?

On Thu, Sep 3, 2015 at 2:33 AM, Ferenc Kovacs wrote: > > 2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ): >> >> Inspired by http://stackoverflow.com/a/12202218/2224584 >> >> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared >> statements off by default, and still allow developer

Re: [PHP-DEV] PDO: Disable emulated prepares by default?

2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ): > > Inspired by http://stackoverflow.com/a/12202218/2224584 > > Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared > statements off by default, and still allow developers to turn it on if > they really want them? > > For now my code

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Thu, Sep 3, 2015 at 12:48 AM, Rowan Collins wrote: > > So I would like to put forward for consideration these amendments to the > proposal, in the spirit of compromise (in no particular order; numbers are > just for reference in future discussion): > > Amendment 1. Only allow the single-express

Re: [PHP-DEV] Heads up: merging security patches to 7

Hi! > I see number of var_push_dtor() to fix unserialization. > var_push_dtor() or var_push_dtor_no_addref() is required always when > php_var_unserialize() is failed. > Am I correct? Not necessarily. Basically, what happens is that when you do php_var_unserialize() the value you unserialize gets

[PHP-DEV] PDO: Disable emulated prepares by default?

Inspired by http://stackoverflow.com/a/12202218/2224584 Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared statements off by default, and still allow developers to turn it on if they really want them? For now my code works around this design decision, but not everybody is cognizant o

Re: [PHP-DEV] Heads up: merging security patches to 7

Hi Stas, On Wed, Sep 2, 2015 at 7:17 AM, Yasuo Ohgaki wrote: > There are many fixes regarding unserialize. > We also had many fixes regarding type mismatches. > I suppose many 3rd party modules have same issues. > > How about have a doc for secure PHP internal coding? I'm writing the draft. I s

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On 02/09/2015 22:49, Sara Golemon wrote: Beautiful code is code that is easier to maintain, and code that is easier to maintain is often more secure and reliable. I think this is an important point. Obviously, "beauty" is subjective: some people will find very verbose, English-like code easier

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Mon, Aug 31, 2015 at 12:29 PM, Bob Weinand wrote: > The short Closures RFC: > https://wiki.php.net/rfc/short_closures > I just want to toss in my two cents as someone who's been using short closures on a PHPish platform for some time already, because predictions are one thing, experience in ano

Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures

On 02/09/2015 20:44, Tom Worster wrote: In other words, ~> will end my career. Thanks :P I know this line is just hyperbole, but it does rather sum up the tone of the rest of your e-mail. I'm honestly not sure how you expect anyone to respond. Scrolling further down, my eye lit on the last

[PHP-DEV] Re: [RFC] [Discussion] Short Closures

I'm 100% with Anthony Ferrara and Tony Marston on this. Another grumpy old curmudgeon (in addition to myself, I mean, not those two) describes four categories of bad stylists: 1. Under educated 2. Old school 3. Thrill seeker 4. Exhibitionist The first two are pretty clear, I think. The Thrill se

[PHP-DEV] PHP 7.1 Cryptography Projects

Hi Scott, I'm clearly very late to this party but, fwiw, ... First: Great! Thank you. This is really needed. Chapeau! Yes, a pluggable back-end is important. OSS crypto libs have some unhappy history and it only makes sense to expect more. When I reviewed cryptography.io, I really liked how the

[PHP-DEV] Re: VCS Account Request: marcio

VCS Account Approved: marcio approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: marcio

Márcio Almada wrote: > This is a an updated request, as asked by Tyrael. This time using the > same email address from my previous git commits. For reference: . -- Christoph M. Becker -- PHP Internals - PHP R

[PHP-DEV] VCS Account Request: marcio

This is a an updated request, as asked by Tyrael. This time using the same email address from my previous git commits. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: marcio

VCS Account Rejected: marcio rejected by tyrael /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

Craig Francis wrote on 02/09/2015 10:06: On 1 Sep 2015, at 19:17, Rowan Collins wrote: I'm still not sure how exists() would be anything other than an alias for array_key_exists(). I think that is the case as well (ish). But considering that isset() seems to be the function that is used mo

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

On 1 Sep 2015, at 19:17, Rowan Collins wrote: > I'm still not sure how exists() would be anything other than an alias for > array_key_exists(). I think that is the case as well (ish). But considering that isset() seems to be the function that is used most of the time, I want to consider why

[PHP-DEV] Re: object_properties_load() does not work for non-string keys - intentional?

Hi! > I don't see the crash. Integer keys are supported in exactly the same > way as it was in PHP-5. I see the crash on this test: https://github.com/smalyshev/php-src/blob/master/ext/spl/tests/bug70155.phpt I'm not sure how integer keys are supported the same way if I see this in the code: h

[PHP-DEV] Benchmark Results for PHP Master 2015-09-02

Results for project php-src-nightly, build date 2015-09-02 05:00:00+03:00 commit: 519016096f911428778d0b88b8701e4d72e88bee revision_date: 2015-09-02 00:28:46+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] Re: object_properties_load() does not work for non-string keys - intentional?

Hi Stas, I don't see the crash. Integer keys are supported in exactly the same way as it was in PHP-5. $ sapi/cli/php -r '$a = [1=>5]; $o = (object)$a; var_dump($o); $s = serialize($o); var_dump($s);var_dump(unserialize($s));' object(stdClass)#1 (1) { [1]=> int(5) } string(27) "O:8:"stdClass