Hi,
On 27 February 2015 at 14:26, Xinchen Hui larue...@gmail.com wrote:
Hey:
On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote:
Hey Internals:
I was looking Bob's switch optimization..
then I start to worry about where is the place optimization should
Hey:
On Fri, Feb 27, 2015 at 2:41 PM, reeze re...@php.net wrote:
Hi,
On 27 February 2015 at 14:26, Xinchen Hui larue...@gmail.com wrote:
Hey:
On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote:
Hey Internals:
I was looking Bob's switch optimization..
Hey:
On Fri, Feb 27, 2015 at 11:44 AM, Yasuo Ohgaki yohg...@ohgaki.net 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
Hi Xinchen,
On Fri, Feb 27, 2015 at 3:55 PM, Xinchen Hui larue...@php.net 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
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é :
Hey:
On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com 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
Hi all,
On Fri, Feb 27, 2015 at 12:44 PM, Yasuo Ohgaki yohg...@ohgaki.net 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
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 larue...@gmail.com 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
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.
Hey:
On Fri, Feb 27, 2015 at 2:59 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Xinchen,
On Fri, Feb 27, 2015 at 3:55 PM, Xinchen Hui larue...@php.net 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
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
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
On Thu, Feb 26, 2015 at 3:57 PM, Zeev Suraski z...@zend.com 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
On 2/26/15, 12:59 AM, Sammy Kaye Powers m...@sammyk.me 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
On 26 February 2015 at 15:37, Tom Worster f...@thefsb.org wrote:
On 2/26/15, 3:48 AM, Stanislav Malyshev smalys...@gmail.com 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
On 26 February 2015 at 16:07, Stefan Esser stefan.es...@sektioneins.de 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
On Thu, Feb 26, 2015 at 2:10 AM, Dmitry Stogov dmi...@zend.com 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.
?php
On Thu, Feb 26, 2015 at 5:27 PM, Tom Worster f...@thefsb.org wrote:
On 2/26/15, 11:07 AM, Stefan Esser stefan.es...@sektioneins.de 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
Leigh and all,
On Thu, Feb 26, 2015 at 11:12 AM, Leigh lei...@gmail.com wrote:
On 26 February 2015 at 15:37, Tom Worster f...@thefsb.org wrote:
On 2/26/15, 3:48 AM, Stanislav Malyshev smalys...@gmail.com wrote:
The custom is that the first word names the function group (yes, I know
old
On 2/26/15, 11:17 AM, Anthony Ferrara ircmax...@gmail.com 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
On 26 February 2015 at 15:04, Tom Worster f...@thefsb.org 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
On 2/26/15, 3:48 AM, Stanislav Malyshev smalys...@gmail.com 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.
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
On Thu, Feb 26, 2015 at 12:48 AM, Stanislav Malyshev
smalys...@gmail.com 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
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 it an
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
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
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
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), Zeev
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
-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
Thanks for your work on this Anthony.
On Thu, Feb 26, 2015 at 2:58 PM, Anthony Ferrara ircmax...@gmail.com
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
On 26 February 2015 at 17:48, Zeev Suraski z...@zend.com 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
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: 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
declarations
2015-02-21 1:45 GMT+01:00 Niklas Keller m...@kelunik.com:
2015-02-21 1:07 GMT+01:00 Pádraic Brady padraic.br...@gmail.com:
On 20 February 2015 at 23:38, Larry Garfield la...@garfieldtech.com
wrote:
While I love the idea, strict type comparison for in would, in essence,
be a
toe-dip into the
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 every line
-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
declarations
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.
Realistically,
Hello,
On Thu, Feb 26, 2015 at 12:49 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 26 February 2015 at 17:48, Zeev Suraski z...@zend.com wrote:
From: Theodore Brown [mailto:theodor...@outlook.com]
2. Strict types are important in some cases.
I would *want* any value with the wrong
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
-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
declarations
-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 at 17:48,
Anthony,
On Thu, Feb 26, 2015 at 1:29 PM, Anthony Ferrara ircmax...@gmail.com
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
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 p...@beccati.com
Zeev,
On Thu, Feb 26, 2015 at 2:18 PM, Zeev Suraski z...@zend.com 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
-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 people
-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 to worry
On Thu, Feb 26, 2015 at 9:28 AM, Theodore Brown theodor...@outlook.com 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
On Thu, Feb 26, 2015 at 3:15 PM, Zeev Suraski z...@zend.com 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
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, we
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 have
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
Hi,
On Thu, Feb 26, 2015 at 9:45 AM, Jacob Bednarz jacob.bedn...@gmail.com 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
On Wed, Feb 25, 2015 at 7:52 PM, Dmitry Stogov dmi...@zend.com 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
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 smalys...@gmail.com
wrote:
This can be prevented by restricting phar archive name or forbid all
URI name at
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.
?php
set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
$expected_type, $value, $file,
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
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 smalys...@gmail.com 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
On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov dmi...@zend.com 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.
?php
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov dmi...@zend.com 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
On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Anthony,
What do you think about using a user level callback
On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov
On Thu, Feb 26, 2015 at 1:43 PM, Joe Watkins pthre...@pthreads.org 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
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 m...@php.net wrote:
Hi,
as already
On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei
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 do
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] that
On Thu, Feb 26, 2015 at 2:34 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov
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 set is
Hi Stas,
On Thu, Feb 26, 2015 at 7:01 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Thu, Feb 26, 2015 at 5:51 PM, Stanislav Malyshev smalys...@gmail.com
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
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
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
likely far more
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 trying to
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com 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
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:
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
Hi Zeev,
On 26 February 2015 at 23:57, Zeev Suraski z...@zend.com 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
On Thu, Feb 26, 2015 at 4:29 PM, Matthew Weier O'Phinney
matt...@zend.com 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
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 to accept
Hi Stas,
On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev smalys...@gmail.com
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,
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
on
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
--
PHP
Hi all,
On Thu, Feb 26, 2015 at 7:06 AM, Yasuo Ohgaki yohg...@ohgaki.net 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
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, but the
Hi Stas,
On Fri, Feb 27, 2015 at 10:50 AM, Stanislav Malyshev smalys...@gmail.com
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
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,
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
must
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
2015-02-24 17:36 GMT+01:00 Benjamin Eberlei kont...@beberlei.de:
Hi,
On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt tho...@gielfeldt.dk
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
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
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
Hi Stas,
On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev smalys...@gmail.com
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
96 matches
Mail list logo
