Hi,
On Sat, Jan 21, 2017 at 11:12 AM, Yasuo Ohgaki wrote:
> On Thu, Jan 19, 2017 at 10:37 PM, Lauri Kenttä
> wrote:
>
>> On 2017-01-19 13:46, Yasuo Ohgaki wrote:
>>
>>> However, PHP as a whole cannot work reliable way w/o CSPRNG and
>>> today's
>>> standard requires working CSPRNG, doesn't it?
Hi Niklas,
On Fri, Jan 20, 2017 at 1:07 AM, Niklas Keller wrote:
> has this been committed? It's just the same BC issue as seeding mt_rand
> with a CSPRNG by default.
Not yet.
I really don't see any pros for caring about failing CSPRNG and fallback to
weak behavior.
1) BC is extremely unlike
Hi Yasuo,
> -Original Message-
> From: Yasuo Ohgaki [mailto:yohg...@ohgaki.net]
> Sent: Saturday, January 21, 2017 2:49 AM
> To: Anatol Belski
> Cc: Niklas Keller ; PHP Internals
> Subject: Re: [PHP-DEV] PHP 7.0.15 available
>
> Hi,
>
> On Sat, Jan 21, 2017 at 10:30 AM, Anatol Belski
Hi Lauri and Leigh,
On Thu, Jan 19, 2017 at 10:37 PM, Lauri Kenttä
wrote:
> On 2017-01-19 13:46, Yasuo Ohgaki wrote:
>
>> However, PHP as a whole cannot work reliable way w/o CSPRNG and
>> today's
>> standard requires working CSPRNG, doesn't it?
>>
>
> No.
>
> Why do you think that PHP can't wor
Hi,
On Sat, Jan 21, 2017 at 10:30 AM, Anatol Belski wrote:
> > Could we change our current system and highlight security issues either
> by color,
> > an icon or even better, by grouping them separately for each release?
> >
> That could be an idea, yes. Currently we have a script to automatical
Hi Niklas,
> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Thursday, January 19, 2017 3:03 PM
> To: Anatol Belski
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] PHP 7.0.15 available
>
> Hey Anatol and others,
>
>
> > Hi,
> >
> > The PHP development team anno
On Fri, Jan 20, 2017 at 1:08 PM, Rasmus Lerdorf wrote:
>
> On Fri, Jan 20, 2017 at 12:58 Nikita Popov wrote:
>
>>
>> That sounds like it could be the source of the issue.
>>
> Ah, that makes more sense than it never hitting that close call because I
> couldn't find any scenario where we wouldn't
On Fri, Jan 20, 2017 at 12:58 Nikita Popov wrote:
>
> From the docs for sqlite3_close():
>
> > If the database connection is associated with unfinalized prepared
>
> statements or unfinished sqlite3_backup objects then sqlite3_close()
>
> will leave the database connection open and return SQLITE_
On Fri, Jan 20, 2017 at 9:13 PM, Rasmus Lerdorf wrote:
> I have been chasing a really odd fd leak which I haven't been able to
> reproduce manually. The code involved is about as simple as you can get:
>
> class C {
> public static function fn($arg) {
> $pdo = new PDO('sqlite:/var/dbs
I have been chasing a really odd fd leak which I haven't been able to
reproduce manually. The code involved is about as simple as you can get:
class C {
public static function fn($arg) {
$pdo = new PDO('sqlite:/var/dbs/file.db');
$query = $pdo->prepare("SELECT * FROM tb WHERE i
On 1/20/2017 7:58 PM, Nikita Popov wrote:
> On Fri, Jan 20, 2017 at 7:55 PM, Stanislav Malyshev
> wrote:
>
>> Hi!
>>
>>> Since the autoloading functions proposal is stalled, how about allowing
>> for
>>> import of static functions instead?
>>>
>>> use function Foo::bar;
>>>
>>> bar(); //
On Fri, Jan 20, 2017 at 7:55 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > Since the autoloading functions proposal is stalled, how about allowing
> for
> > import of static functions instead?
> >
> > use function Foo::bar;
> >
> > bar(); // calls Foo::bar()
>
> I'm not sure why it is good. T
Hi!
> Since the autoloading functions proposal is stalled, how about allowing for
> import of static functions instead?
>
> use function Foo::bar;
>
> bar(); // calls Foo::bar()
I'm not sure why it is good. This would certainly be confusing, if you
call strlen and turns out it's complet
> On Jan 20, 2017, at 01:04, Rasmus Schultz wrote:
>
> Just a quick thought.
>
> Since the autoloading functions proposal is stalled, how about allowing for
> import of static functions instead?
>
>use function Foo::bar;
>
>bar(); // calls Foo::bar()
>
...
> at least we can move ahea
On 1/20/2017 8:04 AM, Rasmus Schultz wrote:
> Just a quick thought.
>
> Since the autoloading functions proposal is stalled, how about allowing for
> import of static functions instead?
>
> use function Foo::bar;
>
> bar(); // calls Foo::bar()
>
> There are two benefits to this approach
Results for project PHP master, build date 2017-01-19 20:28:50-08:00
commit: 71a4247
previous commit:60d075a
revision date: 2017-01-19 10:49:09+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Oops, sorry for an email that just quotes others; mis-clicked send.
> Last, a cosmetic suggestion : replace '$$' with '$<' (more explicit as
> 'input data', imo).
If we aren't going to use `$$` I'd like to use `_` or `__` which read
similar to "fill in the blank" and has precedence in other langu
On Fri, Jan 20, 2017 at 3:53 AM, François Laupretre wrote:
> Le 19/01/2017 à 22:53, Levi Morrison a écrit :
>>
>> On Thu, Jan 19, 2017 at 11:12 AM, François Laupretre
>> wrote:
>>>
>>> Le 19/01/2017 à 13:54, Levi Morrison a écrit :
The `|>` symbol would be the piping operator with these
On mobile, sorry for top posting.
Multiple $$ means the resulting closure will accept multple arguments.
I'm definitely against dropping the ($$) on the right hand side because it
would use non standard symbol lookup rules.
$x = trim;
This normally will look up a constant, and then apply ba
Le 19/01/2017 à 22:53, Levi Morrison a écrit :
On Thu, Jan 19, 2017 at 11:12 AM, François Laupretre wrote:
Le 19/01/2017 à 13:54, Levi Morrison a écrit :
The `|>` symbol would be the piping operator with these semantics:
1. Evaluate the left-hand side.
2. Evaluate the right-hand si
On 20 January 2017 00:59:59 GMT+00:00, Levi Morrison wrote:
>
>I empathize that you don't like string-name callables (I really don't
>like them either) but this RFC helps avoid the string if you want to.
>Consider
>
>// without my proposal:
>array_map('trim', $input)
>
>// with it:
>
21 matches
Mail list logo
