> 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
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
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
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 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,
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
>
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 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
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 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 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
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
> 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 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
>>
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: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 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
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 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
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 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
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
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
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
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 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
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
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
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
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.
>
>
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 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_
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 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 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, 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
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
> -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
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
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
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
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
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 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-
> -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
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: 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
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
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
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
> -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
> -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
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.
>
>
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
> -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
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
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
> -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 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
>
> 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 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
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,
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
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
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
> 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
> 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
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
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
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
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 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
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
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
> 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
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 : 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 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 : 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:
> 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
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
> 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
>
> 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
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]
> 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 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
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
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
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..
> >
> >
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
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
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 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.
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
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
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
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?
>
>
97 matches
Mail list logo
