Jakub, what do you think about back-porting the openssl-1.1 supporting
changes to the PHP-7.0 branch? I think it is too early to have PHP-7.0 not
compile on new Linux versions and right now it doesn't compile on any Linux
that has openssl-1.1.
-Rasmus
On Sat, Jan 21, 2017 at 4:47 PM, Christoph M. Becker
wrote:
>
> Anyhow, the SQLite3 documentation states[1]:
>
> | The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are
> | recommended for all new programs. The two older interfaces are
> | retained for backwards compatibility, but the
On 20.01.2017 at 22:41, Rasmus Lerdorf wrote:
> 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 becaus
Hey guys,
I filed bug 73493 [1] a couple months ago and there's no triage or
visible activity yet. Was hoping to get an update if possible.
I'm forced to download any large INBOX in batches with imap_close() &
imap_open() gymnastics to avoid chewing through 2GB+ of RAM.
thanks!
[1] https:/
On 21/01/2017 17:42, Christoph M. Becker wrote:
In the long run (i.e. for PHP 8) I'd suggest to purge the $num_points
parameter altogether, relying solely on the number of $points given.
Since there's a 4th parameter ($color), what would "purge" mean in this
case? Reducing the number of parame
Hi!
This issue has been filed to our bugtracker years ago[1], but didn't
deserve much attention, so I'm forwarding to the list.
imagepolygon(), imagefilledpolygon() and imageopenpolygon() have the
following signature:
image*polygon(resource $im, array $points, int $num_points, int $col)
Note
Hi, Rasmus!
2017-01-21 4:14 GMT-04:00 Rasmus Schultz :
> > How hard is it to write Foo::bar? You never have to go more
> than one level. I don't see a point in mixing internal function
> namespace with class methods for the sake of saving typing couple of
> characters.
>
> I'm not suggesting we m
>
> I really don't see any pros for caring about failing CSPRNG and fallback
> to weak behavior.
>
> 1) BC is extremely unlikely. Basically, no BC on healthy hardware/OS.
> 2) Then things failed, programs should fail properly. i.e. Shouldn't
> fallback to weaker/problematic code.
>
Failing closed
>
> > Anyway, unusable CSPRNG is very unlikely to happen. I may just use
> > UNEXPECTED macro for the if branch.
> >
>
> I changed my mind due to comment for uniqid() CSPRNG usage.
>
> IMO, there is no benefit for CSPRNG failure fallback. We shouldn't add
> fackback for every CSPRNG usage.
Right,
On 16.01.2017 at 08:04, Yasuo Ohgaki wrote:
> Since I was about to improve uniqid()'s entropy by replacing
> php_combined_lcg() to php_random_int(), I spent time to check other places
> that could be a problem.
>
> mt_rand()'s is seeded as follows by default.
>
> ext/standard/php_rand.h
> #ifdef
> How hard is it to write Foo::bar? You never have to go more
than one level. I don't see a point in mixing internal function
namespace with class methods for the sake of saving typing couple of
characters.
I'm not suggesting we mix namespaces - this of course would be file-local,
same as use-stat
11 matches
Mail list logo