Hi Dan,
I understood about RFC process.
On Wed, Aug 17, 2016 at 12:23 PM, Dan Ackroyd wrote:
> Additionally, you seem to completely have ignored this:
>
> Dan Ackroyd wrote:
>> And I strongly object to the idea of stopping and starting voting on RFCS.
>> Please leave the vote open and if it fai
On 17 August 2016 at 01:30, Yasuo Ohgaki wrote:
> I'll restart vote if I have to make changes,
Yasuo,
No one is asking you to make changes to the RFC. Just leave the voting
open, and then close it on the agreed date.
You would be violating the agreed RFC process* by closing a vote
early, just s
Hi David,
On Wed, Aug 17, 2016 at 12:55 AM, David Walker wrote:
> I raised this concept a couple weeks ago to a couple +1's. Discussion was
> held mostly upon the PR [1], and I went through and documented within the
> RFC [2]. I'd like to go ahead and open up the RFC to voting to the scope
> th
Hi Marco,
On Mon, Aug 15, 2016 at 12:46 PM, Marco Pivetta wrote:
> Besides what reported above by Dan, my reasoning for voting "no" is that
> this API can be implemented in userland, regardless if trivial or not
>
> There is no reason good enough for justifying yet another added endpoint
> that c
Hi Pierre,
On Wed, Aug 17, 2016 at 9:19 AM, Pierre Joye wrote:
> On Aug 15, 2016 10:36 AM, "Yasuo Ohgaki" wrote:
>
>> I don't mind suspend vote for a while to resolve issues if there
>> should be changes in the RFC. I also don't mind adding missing
>> features, e.g. helpful error messages when
On Aug 15, 2016 10:36 AM, "Yasuo Ohgaki" wrote:
> I don't mind suspend vote for a while to resolve issues if there
> should be changes in the RFC. I also don't mind adding missing
> features, e.g. helpful error messages when exception is disabled, to
> my todo list. BTW, I'll document basic idea
To those who voted "no" for this,
On Mon, Aug 15, 2016 at 8:00 PM, Tony Marston wrote:
> "Dan Ackroyd" wrote in message
> news:ca+kxmuriobqpmtekqnyv8rx0gkclryixi--y5tcyukdqpt7...@mail.gmail.com...
>>
>>
>> Hi Yasuo,
>>
>> On 15 August 2016 at 01:53, Yasuo Ohgaki wrote:
>>
>>> One more usual req
Hi Tony,
Allow me to top post.
"The input validation" is not for legitimate users, but for attackers.
You shouldn't help attackers by explaining what/how wrong in attackers' inputs.
I've added discussion "Input validation and User input mistake
handling difference"
https://wiki.php.net/rfc/add_v
Hi Christoph,
On Tue, Aug 16, 2016 at 6:01 PM, Christoph M. Becker wrote:
> On 16.08.2016 at 08:42, Stanislav Malyshev wrote:
>
>>> Yasuo (who Dan quoted here) refers to completely invalid input, such as
>>> invalid UTF-8 byte sequences. I think, that in this case the app should
>>> bail out wit
Hi Stas,
On Mon, Aug 15, 2016 at 2:17 PM, Stanislav Malyshev wrote:
>> It seems there is misunderstanding.
>> These new functions are intended for "secure coding input validation" that
>> should never fail. It means something unexpected in input data that
>> cannot/shouldn't keep program running.
Hi Lester,
On Tue, Aug 16, 2016 at 11:51 PM, Lester Caine wrote:
> On 16/08/16 13:08, Tom Worster wrote:
>>> >The default 128 bits Session ID is large enough to ignore collisions
>>> >https://wiki.php.net/rfc/session-create-id#discussions
>>> >
>>> >It describes for an application, but PHP is a p
Hi Tom,
On Tue, Aug 16, 2016 at 9:08 PM, Tom Worster wrote:
>>> I strongly disagree with this kind of attitude.
>>>
>>> If there are users who really do not want collision detection at all,
>>> they should do it by their own responsibility and risk.
>>
>>Above discussion is added to the RFC.
>>
>
On 16/08/2016 18:15, Christoph M. Becker wrote:
Unless a new active maintainer steps forward, we should consider to move
ext/xml to PECL, in which case the deprecation of utf8_(en|de)code might
be unnecessary.
I don't think that really follows at all. Until this week, I had no idea
that utf8_(
Will up the ante: I wasn't sure the RFC page on voting didn't really define
this, I have no probs with 2/3.
On Tue, Aug 16, 2016 at 11:13 AM Levi Morrison wrote:
> On Tue, Aug 16, 2016 at 11:09 AM, Dan Ackroyd
> wrote:
>
>>
>> > On 16 Aug 2016, at 16:55, David Walker wrote:
>> >
>> > I'd like
On 16.08.2016 at 00:00, Yasuo Ohgaki wrote:
> On Mon, Aug 15, 2016 at 12:17 PM, Yasuo Ohgaki wrote:
>> utf8_decode() and utf8_encode() are not needed and causing problems
>> than solving.
>>
>> https://wiki.php.net/rfc/remove_utf_8_decode_encode
>>
>> Proposal
>> - Document deprecation them now
On Tue, Aug 16, 2016 at 11:09 AM, Dan Ackroyd
wrote:
>
> > On 16 Aug 2016, at 16:55, David Walker wrote:
> >
> > I'd like to go ahead and open up the RFC to voting to the scope
> > that it is written.
>
> Hi David,
>
> Although I will almost certainly be voting yes, the vote does need 2/3's
> to
> On 16 Aug 2016, at 16:55, David Walker wrote:
>
> I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.
Hi David,
Although I will almost certainly be voting yes, the vote does need 2/3's to
pass.
All language changes require that, even if no syntax is change
Hi all,
I raised this concept a couple weeks ago to a couple +1's. Discussion was
held mostly upon the PR [1], and I went through and documented within the
RFC [2]. I'd like to go ahead and open up the RFC to voting to the scope
that it is written.
--
Dave
[1] https://github.com/php/php-src/pu
Hi Lester,
On 16/08/2016 16:16, Lester Caine wrote:
I have no
problems with the test side and we have a stable test suite for testing
against outside of PHP but many of the 'changes' in the code base ARE
generic changes to some core process and trying to mirror them into an
unmaintained extensio
On 16/08/16 15:55, Rowan Collins wrote:
> I'm sure everyone agrees is that the ideal situation is *not* to drop
> it, and instead to find someone willing to commit to maintain it. But
> there's no point saying it's maintained if nobody is actually performing
> that role.
While my name is not again
Results for project PHP master, build date 2016-08-16 17:04:27+03:00
commit: befca6a
previous commit:d4bbbc4
revision date: 2016-08-16 12:43:46+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 16/08/2016 11:11, Lester Caine wrote:
There have been several 'attempts' to drop ext/interbase, all well
documented on this list. PHP developers may not think Firebird is very
popular, and probably from a PHP base it isn't but it IS used
extensively in large areas of the World.
Please carefu
On 16/08/16 13:08, Tom Worster wrote:
>> >The default 128 bits Session ID is large enough to ignore collisions
>> >https://wiki.php.net/rfc/session-create-id#discussions
>> >
>> >It describes for an application, but PHP is a platform.
>> >There are millions PHP apps or more and there could be billi
Hey all,
Can we please reach a resolution on this?
- Davey
On Sun, Aug 7, 2016 at 9:04 AM, Davey Shafik wrote:
> AFAICT, to make this change, I'd have to modify:
>
> ZEND_API ZEND_COLD void zend_internal_type_error(zend_bool
> throw_exception, const char *format, ...) /* {{{ */
>
> To be:
>
>
On 8/15/16, 5:39 PM, "Yasuo Ohgaki" wrote:
>On Tue, Aug 16, 2016 at 6:03 AM, Yasuo Ohgaki wrote:
>> On Tue, Aug 16, 2016 at 5:21 AM, Tom Worster wrote:
>>> On 8/14/16 4:13 PM, Yasuo Ohgaki wrote:
>>>
"Now assume a 128 bit session identifier that provides 64 bits of
entropy.
>>>
>>>
>>
On 16/08/16 02:11, Kalle Sommer Nielsen wrote:
> 2016-08-16 1:27 GMT+02:00 Lester Caine :
>> None of the listed bugs are a problem in normal use. Some WERE fixed in
>> previous code, but those fixes were not merged with the master code base
>> in pre git days :(
>
> So you are saying that in your
Hi!
On 16.08.2016 at 08:42, Stanislav Malyshev wrote:
>> Yasuo (who Dan quoted here) refers to completely invalid input, such as
>> invalid UTF-8 byte sequences. I think, that in this case the app should
>> bail out without even given detailed information, as such grossly
>> invalid input most l
> On 15 Aug 2016, at 04:35, Yasuo Ohgaki wrote:
>
> Hi Dan,
>
> I don't mind suspend vote for a while ...
>
> It seems you aren't objecting the idea itself.
I do object to the concept of the RFC. In my first point I said it belongs in
userland.
And I strongly object to the idea of stopping
28 matches
Mail list logo
