> Since I am very much in favour of scalar type hints, I've updated the
> patch to master and made some minor improvements, and I am re-opening
> the RFC with the intent to try and get it into PHP 5.7.
First of all, this is my first reply on PHP Internals so I hope I am doing it
right. :)
Thank
On Thu, Jul 17, 2014 at 9:18 PM, Tjerk Meesters
wrote:
>
>
>
> On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig wrote:
>
>>
>>
>>
>> On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters > > wrote:
>>
>>>
>>>
>>>
>>> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig
>>> wrote:
>>>
On Thu, Jul 17, 2014 at
On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig wrote:
>
>
>
> On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters
> wrote:
>
>>
>>
>>
>> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig
>> wrote:
>>
>>> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>>>
>>> >
>>> > On 17 Jul 2014, at 10:24, Nikit
On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters
wrote:
>
>
>
> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig wrote:
>
>> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>>
>> >
>> > On 17 Jul 2014, at 10:24, Nikita Popov wrote:
>> >
>> > > This is already what is currently happening, see
On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig wrote:
> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>
> >
> > On 17 Jul 2014, at 10:24, Nikita Popov wrote:
> >
> > > This is already what is currently happening, see
> > > http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067.
> >
On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>
> On 17 Jul 2014, at 10:24, Nikita Popov wrote:
>
> > This is already what is currently happening, see
> > http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067.
> >
> > Andreas proposal is only useful in the case that the numbers do
Yasuo
> Anthony, do you have suggestion for removing 72 char restriction of
> PASSWORD_BCRYPT?
My suggestion is to leave it there (it's no longer bcrypt if you do
something to remove it). Here's a deeper explanation:
http://stackoverflow.com/a/16597402/338665
Once scrypt (or yescrypt, or whateve
Hi all,
On Fri, Jul 18, 2014 at 4:38 AM, Anthony Ferrara
wrote:
> We internalized the algorithms in 5.3.2 at least partially because the
> system provided libraries were inconsistent at best (hence why many
> but not all 5.2 systems don't support bcrypt, it depended on the build
> of libcrypt yo
Hi
I want to help translating the PHP documentation.
For some time I have contributed in PHP translation projects for Symfony2
(https://github.com/andreia/symfony-docs-pt-BR/), DBAL
(https://github.com/royopa/dbal-documentation- en_US) and Silex Framework
(https://github.com/royopa/silex-documen
All,
Look at the issue, there's a line in there that is the crux of the issue:
> So problem isn't only in ROUNDS_MIN.
In fact, the overall algorithm changed.
Look at a quick example: http://3v4l.org/Eov3o
>From 5.3.2+ (when we pulled in our own implementation of crypt-sha256
and crypt-sha512,
Apologies, I pasted the wrong code, it should have read:
"
which makes the code:
> function foo( $i, $s )
> {
>$i = (int) $i;
>$s = (string) $s;
> }
Not be equivalent to:
> function foo( (int) $i, (string) $s )
> {
> }
As the type-hint information is no
Hi Thomas,
> Perhaps I miss your point. But what is the difference to current behavior if
> you do not know about the types?
Not to the current behaviour, to the behaviour that would be possible
with scalar type-hinting.
>Or is your point about inspection of parameter type? Why shouldn't refle
On 16 July 2014 23:16, Tjerk Meesters wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
>
>> Hi Tjerk,
>>
>> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters > > wrote:
>>
>>> Why should `password_verify()` work on a hash that wasn't generated with
>>> `password_hash()`? The fact tha
On 17 Jul 2014, at 10:24, Nikita Popov wrote:
> This is already what is currently happening, see
> http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067.
>
> Andreas proposal is only useful in the case that the numbers don't divide
> exactly and you need round-down/truncation behavior an
> - I'd like to have E_CAST on all castings/type jugglings even if we do
> not get scalar type hinting.
$var = 6.3;
$a = (int) $var;
Or $b = (bool) "1";
This is usual code and it could be wanted to losse information on casting.
Triggering errors for that would be extremely annoying.
> - I pr
Hi Dan,
On 07/17/2014 02:12 PM, Dan Ackroyd wrote:
Thomas Nunninger wrote:
- "scalar parameter casting" should just be a convenience for coding:
function foo( (int) $i, (string) $s )
{
}
is the same as:
function foo( $i, $s )
{
$i = (int) $i;
Thomas Nunninger wrote:
> - "scalar parameter casting" should just be a convenience for coding:
>
> function foo( (int) $i, (string) $s )
> {
> }
>
>is the same as:
>
> function foo( $i, $s )
> {
>$i = (int) $i;
>$s = (string) $s;
> }
>
>or perh
> -Original Message-
> From: Alain Williams [mailto:a...@phcomp.co.uk]
> Sent: Wednesday, July 16, 2014 11:17 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> On Wed, Jul 16, 2014 at 09:31:46AM +0100, Rowan Collins wrote:
>
>
Hi Pierre,
On Thu, Jul 17, 2014 at 3:52 PM, Pierre Joye wrote:
> On Thu, Jul 17, 2014 at 1:02 AM, Yasuo Ohgaki wrote:
> > RFC for this is created.
> >
> > https://wiki.php.net/rfc/use-php_mt_rand
> >
> > New rand() function name is TBD. I cannot think of good name, but
> > I like rand_system().
Hi Tjerk,
On Thu, Jul 17, 2014 at 3:16 PM, Tjerk Meesters
wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
>
>> Hi Tjerk,
>>
>> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters <
>> tjerk.meest...@gmail.com> wrote:
>>
>>> Why should `password_verify()` work on a hash that wasn't g
Hi all,
https://github.com/php/php-src/pull/725
This is the fix for https://bugs.php.net/bug.php?id=66827
This kind of malformed data is an attack most likely, but
raising error is not an option.
Quick grep show no module nor core log error only.
i.e. There is no error logging only code. All of
Hi,
On 07/16/2014 10:45 PM, Andrea Faulds wrote:
On 16 Jul 2014, at 21:43, Zeev Suraski wrote:
anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.
Right, so it needs to be fixed. It makes no sense to force a new agenda
on the language that's i
On Thu, Jul 17, 2014 at 2:25 AM, Sara Golemon wrote:
> On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds wrote:
> > Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be
> subject to change, though I think it’s the best I’ve heard so far. ;)
> >
> Nor am I. Here's a thought though:
On Thu, Jul 17, 2014 at 9:58 AM, Stas Malyshev
wrote:
> Hi!
>
> > As discussed in previous threads about this failure, we (doctrine) can
> > move away from the `unserialize()` hack if
> > `ReflectionClass#newInstanceWithoutConstructor()` provides support for
> > internal classes.
>
> Could you ex
Hi!
> As discussed in previous threads about this failure, we (doctrine) can
> move away from the `unserialize()` hack if
> `ReflectionClass#newInstanceWithoutConstructor()` provides support for
> internal classes.
Could you explain why it is needed to instantiate internal classes
without calling
On Thu, Jul 17, 2014 at 8:43 AM, Stas Malyshev
wrote:
> Hi!
>
> > IMHO this isn't something we should change in a 2nd digit release, but
> on a
> > major version, even if it wasn't documented.
>
> We don't have much option here. Keeping it leads to a remote triggerable
> segfaults. We've discusse
On 17 Jul 2014, at 08:17, Stas Malyshev wrote:
> Hi!
>
>> * Time (actually pretty common in web apps, though we have a DateTime
>> class)
>
> Admittedly, we're getting closer to the dreaded year 2038, but what does
> it actually mean to divide current Unix timestamp by 3 and why one would
> ev
On 17/07/14 08:02, Zeev Suraski wrote:
> I think it is, given I believe it's the first time people are asking for
> this after PHP's been out for almost two decades...
> As the RFC itself suggests, you can use the current division for most use
> cases, including the ones mentioned above - they'd wo
On 17 Jul 2014, at 08:19, Zeev Suraski wrote:
> PHP's not Perl. Let's keep it that way please…
> I don't think it makes sense to add a
> specialized integer division operator when we do have a different division
> operator, and I don't think other dynamic languages have such an operator
> - so
On 17/07/14 04:23, Sara Golemon wrote:
> Wow. I just finally understood what your RFC was going for. I thought
> you were trying to cover the case where ($a%$b)==0, but you're not,
> you're trying to do truncated integer division regardless of
> remainder. I also missed the fact that div_function
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, July 17, 2014 10:09 AM
> To: Zeev Suraski
> Cc: bis...@php.net; PHP internals
> Subject: Re: [PHP-DEV] [RFC] intdiv()
>
>
> On 17 Jul 2014, at 08:02, Zeev Suraski wrote:
>
> > I think it is, given I believe i
Hi!
> * Time (actually pretty common in web apps, though we have a DateTime
> class)
Admittedly, we're getting closer to the dreaded year 2038, but what does
it actually mean to divide current Unix timestamp by 3 and why one would
ever want to do this? We also have classes for real datetime calcu
On 17 Jul 2014, at 08:02, Zeev Suraski wrote:
> I think it is, given I believe it's the first time people are asking for
> this after PHP's been out for almost two decades...
> As the RFC itself suggests, you can use the current division for most use
> cases, including the ones mentioned above -
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, July 17, 2014 9:44 AM
> To: Zeev Suraski
> Cc: bis...@php.net; PHP internals
> Subject: Re: [PHP-DEV] [RFC] intdiv()
>
>
> On 17 Jul 2014, at 07:29, Zeev Suraski wrote:
>
> > From debating whether it's worth
34 matches
Mail list logo
