On Aug 31, 2016, at 11:49, Yasuo Ohgaki wrote:
>
> I remember an argument that "function" is useful to "grep functions".
> This is true, but we have tokenizer and tokenizer does better job.
> e.g. It excludes functions inside comments.
>
> It may be time to consider simplifying things.
Perhaps,
> On Wed, Aug 31, 2016 at 7:49 AM David Walker wrote:
> Hi all,
>
> As of now, the scheduled time the vote is to close, the RFC stands 19-4
> (accepted). Given this is my first solo RFC, I'm not really sure protocol
> to go from here. Dmitry does raise that the implementation I put forward
> may
On Wed, Aug 24, 2016 at 9:26 AM David Walker wrote:
> Hi,
>
> I'd like to open voting on my RFC[1] to implement getaddrinfo(). The RFC
> implements 4 new socket extension functions to aid in the calling,
> examining, and connect/binding of the addrinfo structure.
>
> --
> Dave
>
> [1] - https://
On Wed, Aug 31, 2016 at 7:49 AM David Walker wrote:
> On Wed, Aug 31, 2016 at 7:48 AM David Walker wrote:
>
>> I too get Dmitry's result. As the left hand side is an error-zval, and
>> the right hand is null, it explodes. Yes, the hackish way I try and
>> resolve things was to check opcodes ar
2016-09-01 0:09 GMT+02:00 Adam Baratz :
> One note I missed: it probably goes without saying that I'd like write
> access to ext/pdo_dblib, but write access to ext/pdo would also help for
> work on common unit tests and functionality.
+1, Adam have done great work at trying to keep pdo_dblib alive
One note I missed: it probably goes without saying that I'd like write
access to ext/pdo_dblib, but write access to ext/pdo would also help for
work on common unit tests and functionality.
On Tue, Aug 30, 2016 at 4:00 PM, Adam Baratz wrote:
> Maintain pdo_dblib extension.
>
>
> --
> PHP Internal
Hi all,
On Mon, Aug 15, 2016 at 9:15 AM, Yasuo Ohgaki wrote:
>
> This RFC is to add functions that are suitable for input validations
> for secure coding. IMHO, these additions are mandatory for PHP.
>
> https://wiki.php.net/rfc/add_validate_functions_to_filter
> Vote ends 2016/08/22 23:59:59 UTC
On Mon, Aug 29, 2016 at 10:22 PM, Arvids Godjuks
wrote:
> As was said, this was debated a lot. Both sides had valid arguments, but
> this should not be taken lightly just because there is no "BC break". There
> is such thing as too much syntactic sugar, and PHP is one of those, rare
> these days,
Results for project PHP master, build date 2016-08-31 06:24:31+03:00
commit: abe3ce5
previous commit:2d72fcc
revision date: 2016-08-30 18:07:28+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Wed, Aug 31, 2016 at 7:48 AM David Walker wrote:
> I too get Dmitry's result. As the left hand side is an error-zval, and
> the right hand is null, it explodes. Yes, the hackish way I try and
> resolve things was to check opcodes around the current one, which I should
> have thought in the c
I too get Dmitry's result. As the left hand side is an error-zval, and the
right hand is null, it explodes. Yes, the hackish way I try and resolve
things was to check opcodes around the current one, which I should have
thought in the case of addition wouldn't have been valid. The entire goal
of
On 31.08.2016 at 12:10, Dmitry Stogov wrote:
> no. if you would try the proposed PR with this code, you would see:
>
>
> Fatal error: Uncaught Error: Unsupported operand types
I get the following behavior against PR #1269:
$ sapi/cli/php -n -d error_reporting=-1 -r "\$a = [null]; \$c = null;
v
Ah, thanks, I thought it was silently passing :-)
On 31 Aug 2016 12:10 p.m., "Dmitry Stogov" wrote:
> no. if you would try the proposed PR with this code, you would see:
>
>
> Fatal error: Uncaught Error: Unsupported operand types
>
> --
> *From:* Marco Pivetta
> *Se
no. if you would try the proposed PR with this code, you would see:
Fatal error: Uncaught Error: Unsupported operand types
From: Marco Pivetta
Sent: Wednesday, August 31, 2016 10:10:23 AM
To: Dmitry Stogov
Cc: Christoph M. Becker; PHP Internals List; Nikita Popo
RFC proposes to emit warning, but the provided code throws unrelated
"Unsupported operand types" exception.
I see, that after few weeks of work, the implementation (just few lines of C
code) is still hackish and incomplete.
This makes me think that, the feature can't be cleanly implemented, an
Dmitry Stogov schrieb am Mi., 31. Aug. 2016, 08:37:
> I vote NO, because the implementation introduces more problems than
> intents to fix.
>
> For example the following code starts to throw exception:
>
>
>
>
Array access on null should always throw IMO.
BTW, I'm not against the feature, I'm
Hi Dmitry,
On 31 Aug 2016 8:37 a.m., "Dmitry Stogov" wrote:
>
> I vote NO, because the implementation introduces more problems than
intents to fix.
>
> For example the following code starts to throw exception:
>
>
>
Isn't that the point of this RFC?
I would expect this code to only ever work by
17 matches
Mail list logo
