Hey:
On Tue, Aug 2, 2016 at 2:21 PM, Benjamin Coutu wrote:
> Hello Xinchen,
>
> Thanks for implementing.
> Unfortunatly we just broke array_column by mistake. My description might
> not have been clear enough.
>
> We can only create a packed array when $index_key=null AND if the input
> array wa
Hi,
cause of my english, I think it's not good idea to wrote new RFC. But, there is
feature which missing in PHP 7+. As you release new PHP version with type
hinting and return type, you forgot for objects array like in JAVA or .NET
For better understand there is example of syntax in JAVA
Playe
On 01/08/16 23:51, Yasuo Ohgaki wrote:
> PHP must have input validation feature that achieves previously
> described validation. Basic feature like input validation must be able
> to perform quickly, so it should be provided as core feature like
> basic escaping functions.
>
> Regards,
>
> P.S. I
Hey
On Thu, Jul 28, 2016 at 4:59 PM, Benjamin Coutu wrote:
> Hello Xinchen,
>
> I have noticed two more cases where we could easily use packed arrays.
>
> 1. array_merge($packed1, $packed2, ...):
>
> In the quite common case where all arguments are packed arrays, the
> resulting array can also b
Sara Golemon wrote:
> Feeling "meh" on it (neither for nor against), but I would consider
> consistency with other str*() functions by making case-insensitivity
> live in separate functions rather than as a parameter. e.g.
> str_begins(), str_ibegins(), str_ends(), end_iends()
I guess that "i" isn
On Mon, Aug 1, 2016 at 3:27 PM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
> On Mon, Aug 1, 2016 at 3:16 PM, Davey Shafik wrote:
>
>> On Mon, Aug 1, 2016 at 1:13 PM, Charles R. Portwood II <
>> charlesportwoo...@erianna.com> wrote:
>>
>>>
>>> On Mon, Aug 1, 2016 at 2:41 PM, Da
On Tue, Aug 2, 2016 at 7:56 AM, Sara Golemon wrote:
> On Mon, Aug 1, 2016 at 3:52 PM, wrote:
>> I recently emailed the group about submitting an RFC for str_begins() and
>> str_ends() functions. The RFC has now been officially submitted and is
>> viewable at:
>>
>> https://wiki.php.net/rfc/add_s
Hi all,
On Tue, Aug 2, 2016 at 7:12 AM, Yasuo Ohgaki wrote:
>
> Raising Exception would be prefered.
> Any comment raising exception? ExceptionFilterValidate wouldn't
> cause much BC, IMO.
Any comments on using SPL exception?
http://php.net/manual/en/class.unexpectedvalueexception.php
With Exce
On Mon, Aug 1, 2016 at 3:52 PM, wrote:
> I recently emailed the group about submitting an RFC for str_begins() and
> str_ends() functions. The RFC has now been officially submitted and is
> viewable at:
>
> https://wiki.php.net/rfc/add_str_begin_and_end_functions
>
Feeling "meh" on it (neither fo
Hello,
I recently emailed the group about submitting an RFC for str_begins()
and str_ends() functions. The RFC has now been officially submitted and
is viewable at:
https://wiki.php.net/rfc/add_str_begin_and_end_functions
The github PR may be found at:
https://github.com/php/php-src/pull/20
Hi Dan,
On Tue, Aug 2, 2016 at 7:29 AM, Dan Ackroyd wrote:
> On 1 August 2016 at 09:23, Yasuo Ohgaki wrote:
>>
>> Question is which version should I target for?
>
> Why does this need to be in PHP core?
Input validation is the most important security measure.
https://www.securecoding.cert.org/
On 1 August 2016 at 09:23, Yasuo Ohgaki wrote:
>
> Question is which version should I target for?
Why does this need to be in PHP core?
Why can't this just be a userland library?
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub
Hi David,
The updated section still doesn't really describe the BC break that well.
Some people will need to change their code to avoid having notices
raised frequently. How difficult that will be needs to be thought
about.
Additionally, although the default ini files may turn off notices in
pro
On Mon, Aug 1, 2016 at 5:23 PM, Yasuo Ohgaki wrote:
> We have filter_var_array()/filter_input_array() currently. They are
> designed as filter functions. i.e. They convert offending elements to
> NULL/FALSE. Therefore, it's difficult to validate and see if inputs
> are valid with specified specif
Hi Christoph,
On Mon, Aug 1, 2016 at 7:08 PM, Christoph Becker wrote:
>> We have filter_var_array()/filter_input_array() currently. They are
>> designed as filter functions. i.e. They convert offending elements to
>> NULL/FALSE. Therefore, it's difficult to validate and see if inputs
>> are vali
On Mon, Aug 1, 2016 at 2:41 PM, Davey Shafik wrote:
> On Mon, Aug 1, 2016 at 12:35 PM, Davey Shafik wrote:
>
>> On Mon, Aug 1, 2016 at 10:46 AM, Charles R. Portwood II <
>> charlesportwoo...@erianna.com> wrote:
>>
>>> Hello,
>>> The RFC for introducing Argon2 as an alternative hashing
On 1 August 2016 at 18:46, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
> Hello,
>
> The RFC for introducing Argon2 as an alternative hashing algorithm for the
> password_* functions is now open. The RFC is available at
> https://wiki.php.net/rfc/argon2_password_hash.
>
> Voting
Hello,
The RFC for introducing Argon2 as an alternative hashing algorithm for the
password_* functions is now open. The RFC is available at
https://wiki.php.net/rfc/argon2_password_hash.
Voting is open for 1 week, and will close on August 8th with a 50%+1
majority required to pass. If either of t
> Thanks, please add start and end dates for voting.
Done. Voting is open till August 6, but I think the result is already clear)
> but after building I've got segfaults
Probably it is because I didn't add PHP_FE_END at the end of function list.
> My *main* issue with this RFC is that I don't con
On 30.07.2016 at 17:09, Michael Vostrikov wrote:
> Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
> now in voting phase.
>
> https://wiki.php.net/rfc/escaping_operator
I just checked out the cde_new branch to verify the behavior of some
potential edge cases, but afte
On 01.08.2016 at 10:23, Yasuo Ohgaki wrote:
> We have filter_var_array()/filter_input_array() currently. They are
> designed as filter functions. i.e. They convert offending elements to
> NULL/FALSE. Therefore, it's difficult to validate and see if inputs
> are valid with specified specifications
Results for project PHP master, build date 2016-08-01 06:27:38+03:00
commit: b6f3efd
previous commit:bcc40a7
revision date: 2016-07-31 15:02:44+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hi Dan,
I left it blank to go along with default production ini-settings where
notices would be excluded. However, you are probably correct that it should
be noted for development environments as something new. I'll toss it in
there in the morning
Thanks
--
Dave
On Mon, Aug 1, 2016 at 01:14 Dan A
Hi all,
We have filter_var_array()/filter_input_array() currently. They are
designed as filter functions. i.e. They convert offending elements to
NULL/FALSE. Therefore, it's difficult to validate and see if inputs
are valid with specified specifications.
https://github.com/php/php-src/pull/2048
Hi David,
On 31 July 2016 at 20:31, David Walker wrote:
> So I want to solicit for more discussion given previous talks. My
> first-attempt RFC for this is at:
> https://wiki.php.net/rfc/notice-for-non-valid-array-container
>
I've very likely to support this RFC, however the section on 'Backwar
25 matches
Mail list logo
