On Wed, Apr 29, 2015 at 12:24 PM, François Laupretre franc...@php.net
wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
I would suggest then to end the white card given with the php7 rfc
+1 on this. How can we make it official ? How can we stop the changes
merged to the PHP 7 branch
Howdy
Back when PHP6 was actually a thing, we added the 'b' string literal
prefix and the (binary) cast to be forward compatible with PHP6,
however since the entire unicode strings part were dropped, these are
no longer needed.
I think its safe to remove these 2, and take it as a lession
Hi Patrick
2015-04-29 0:10 GMT+02:00 Patrick ALLAERT patrickalla...@php.net:
No go? Isn't that a bit rough?
Well we need to be fair and hold our own policies/processes we agree
to true, else there is no point in having them.
That kind of change normally doesn't require an RFC at all. We did
Le mer. 29 avr. 2015 à 03:19, Pierre Joye pierre@gmail.com a écrit :
On Apr 29, 2015 5:38 AM, Adam Harvey ahar...@php.net wrote:
On 28 April 2015 at 15:10, Patrick ALLAERT patrickalla...@php.net
wrote:
Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen ka...@php.net a
écrit :
On Wed, Apr 29, 2015 at 12:37 AM, Adam Harvey ahar...@php.net wrote:
So, please, show respect for the people working hard on PHP 7.0 [...]
Whoa, the show respect for the people that work card already ?
Let's all chill. Here are some kitteh.
http://lol.cat/3z
by not trying to push something in
-Original Message-
From: Ferenc Kovacs [mailto:tyr...@gmail.com]
Sent: Wednesday, April 29, 2015 2:54 PM
To: franc...@php.net; Zeev Suraski
Cc: Pierre Joye; Adam Harvey; Patrick ALLAERT; Olivier Garcia; PHP
Internals;
Kalle Sommer Nielsen
Subject: Re: [PHP-DEV] [RFC][VOTE] Improved
Le mer. 29 avr. 2015 à 10:57, Kalle Sommer Nielsen ka...@php.net a écrit :
I would love to see more work toward identifying issues in PHP7, and
hopefully we can get that once we release the first alpha.
The issue targeted here is two extensions overriding php_error_cb can't
live side by side
De : Ferenc Kovacs [mailto:tyr...@gmail.com]
For PHP7 we had a previously voted on and accepted timeline
(https://wiki.php.net/rfc/php7timeline) which stated marc 15 as
the last time for RFCs targetting php7, and as far as I can tell, everybody
seemed to agree that any RFC targetting
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
http://3v4l.org/6J0bZ
I don't
De : Pierre Joye [mailto:pierre@gmail.com]
I would suggest then to end the white card given with the php7 rfc
+1 on this. How can we make it official ? How can we stop the changes merged to
the PHP 7 branch every day ? Start a 7.1 branch ?
François
--
PHP Internals - PHP Runtime
De : kalle@gmail.com [mailto:kalle@gmail.com] De la part de Kalle
Sommer Nielsen
Back when PHP6 was actually a thing, we added the 'b' string literal
prefix and the (binary) cast to be forward compatible with PHP6,
however since the entire unicode strings part were dropped, these
Am 21.03.2015 um 18:05 schrieb Sebastian Bergmann:
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.
Thoughts?
ping
--
PHP Internals - PHP Runtime
Found something else today
http://3v4l.org/mO48q
echo [1, 2, 3] = []; // 1 but it gives 3
On Mon, Apr 20, 2015 at 7:29 PM, Pasindu De Silva ppasin...@gmail.com
wrote:
Hi
Found this while trying to do the documentation, Thought the same that it
was a RFC mistake,
therefore didn't put any
On 29 April 2015 at 14:21, Anatol Belski anatol@belski.net wrote:
after the recent discussion on IRC I would like to express the rediness to
take on this job. As Kalle is willing to take this role as well, it'd
probably make sense to hear what everyone thinks about my proposition.
Hi Stas and Ryan,
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas derokor...@gmail.com wrote:
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
This is exactly
Hi Francois,
On Wed, Apr 29, 2015 at 7:03 PM, François Laupretre franc...@php.net
wrote:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
This has been a big issue that I have ran into many times in the past for
large framework projects, instead of building it out with strict types
like: int, float, string, exc... It makes more sense to allow a user to
define a psudo-type themselves which PHP will pass the arguments into to be
Hi Christoph,
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de wrote:
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas derokor...@gmail.com
wrote:
I agree with Stanislav here, if you want to accept any type of number,
its
easy enough to add your own checking to do that
Yasuo Ohgaki wrote:
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas derokor...@gmail.com wrote:
I agree with Stanislav here, if you want to accept any type of number, its
easy enough to add your own checking to do that with the wonderful
is_numeric. And for simplicity, make an invalidArgument
Hi Francois,
On Thu, Apr 30, 2015 at 6:23 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Allowing any forms of int/float as string(and GMP) for weak mode int/float
type hint
would be alternative resolution for this issue. I think it's better than
numeric type
hint.
It seems current
Hi!
The objective to have type hint is to remove such checks by users,
isn't it?
No, not really. The objective is to ensure type of the parameter. If you
checks are not limited to types, then typing is not going to help, and I
don't think inventing special built-in type for each narrow use
Hi!
The issue targeted here is two extensions overriding php_error_cb can't
live side by side and that issue exists since PHP 4.0. Should a bug report
be opened?
I'm not sure why can't they live side by side. Of course, if the
override is made in incompatible manner, they can't, but the same
Yasuo Ohgaki wrote:
On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
PHP types are not machine native types. But yes, it forces PHP type -
that's why it is *type* check.
Type hint is better to stay as hint under weak mode. IMO.
Type hints have never been
Hi Yasuo,
Yasuo Ohgaki wrote:
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de wrote:
A solution for this issue has been proposed by the Big Integer Support
RFC which has been withdrawn. It's too late for PHP 7.0 to re-open it,
but it might be reasonable to to so for
On 30/04/15 00:41, Christoph Becker wrote:
Hi everybody!
I've noticed that the Reserve Even More Types in PHP 7 RFC[1] has been
moved to Process and Policy with the comment needs no impl.
However, the RFC states:
| This RFC does not fully reserve them as keywords; it only prohibits
| their
Hi Christoph,
On Thu, Apr 30, 2015 at 7:10 AM, Christoph Becker cmbecke...@gmx.de wrote:
Yasuo Ohgaki wrote:
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de
wrote:
A solution for this issue has been proposed by the Big Integer Support
RFC which has been withdrawn.
Hi!
Back when PHP6 was actually a thing, we added the 'b' string literal
prefix and the (binary) cast to be forward compatible with PHP6,
however since the entire unicode strings part were dropped, these are
no longer needed.
I think its safe to remove these 2, and take it as a lession
Hi Stas,
On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
The objective to have type hint is to remove such checks by users,
isn't it?
No, not really. The objective is to ensure type of the parameter. If you
checks are not limited to types, then typing is not
On Thu, Apr 30, 2015 at 2:45 AM, Leigh lei...@gmail.com wrote:
On 29 April 2015 at 14:21, Anatol Belski anatol@belski.net wrote:
after the recent discussion on IRC I would like to express the rediness to
take on this job. As Kalle is willing to take this role as well, it'd
probably make
Hi!
You can cast your vote on the Wiki [1] and the according patch is
available as a Pull Request [2].
Vote will be open for two weeks, counting from today.
I think the idea of this RFC is nice but it needs a bit more work to
make it really good and successful. See some of the notes below
Hi everybody!
I've noticed that the Reserve Even More Types in PHP 7 RFC[1] has been
moved to Process and Policy with the comment needs no impl.
However, the RFC states:
| This RFC does not fully reserve them as keywords; it only prohibits
| their usage as class, interface and trait names.
In
Stanislav Malyshev wrote:
Yeah compare_function can actually return more than 1, 0 and -1, esp.
for arrays but maybe . I'm not sure if we should change this or not. It
should be pretty easy to fix, just not sure why it's this way now - see
zend_compare_arrays and down to zend_hash_compare.
Hi Nathan,
On Thu, Apr 30, 2015 at 6:41 AM, Nathan Bruer nathanbr...@gmail.com wrote:
This has been a big issue that I have ran into many times in the past for
large framework projects, instead of building it out with strict types
like: int, float, string, exc... It makes more sense to allow
Hi!
Found something else today
http://3v4l.org/mO48q
echo [1, 2, 3] = []; // 1 but it gives 3
Yeah compare_function can actually return more than 1, 0 and -1, esp.
for arrays but maybe . I'm not sure if we should change this or not. It
should be pretty easy to fix, just not sure why it's
hi Julien.
On Wed, Apr 29, 2015 at 10:50 PM, Julien Pauli jpa...@php.net wrote:
On Wed, Apr 29, 2015 at 3:57 PM, Anatol Belski anatol@belski.net
wrote:
On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote:
On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski anatol@belski.net
wrote:
Hi!
If you need to force to map value to PHP type, you have strict mode.
Weak
mode is just too strict currently even if PHP handled int/float/string as
integer/float including invalid values traditionally.
That is what was decided by votes - to make type conversions fail on
values that can
Hi!
we asked for feedbacks on the matter [1] [2], stating from the very
beginning that, to our understanding, it wasn't a feature but code
gardening.
I think introducing new engine APIs, to be used by extensions, is not
something that should be taken lightly as mere refactoring. If the
On Apr 29, 2015 8:11 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Ferenc Kovacs [mailto:tyr...@gmail.com]
Sent: Wednesday, April 29, 2015 2:54 PM
To: franc...@php.net; Zeev Suraski
Cc: Pierre Joye; Adam Harvey; Patrick ALLAERT; Olivier Garcia; PHP
Internals;
Sounds good too :)
Three will have plenty to do very soon
On Apr 29, 2015 8:35 PM, Ferenc Kovacs tyr...@php.net wrote:
On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski anatol@belski.net
wrote:
Hi,
On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote:
bumping the thread as we should start
On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski anatol@belski.net
wrote:
Hi,
On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote:
bumping the thread as we should start the release steps (branching out
7.0,
tagging the first alpha or more likely beta) if we wanna keep up with
Hi,
On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote:
bumping the thread as we should start the release steps (branching out
7.0,
tagging the first alpha or more likely beta) if we wanna keep up with
https://wiki.php.net/rfc/php7timeline
after the recent discussion on IRC I would like to
On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote:
On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski anatol@belski.net
wrote:
Hi,
On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote:
bumping the thread as we should start the release steps (branching
out 7.0,
tagging the first alpha or
Hi!
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.
Thoughts?
It's kind of hard to recover the context here, but I assume it's
Hi Christoph,
On Thu, Apr 30, 2015 at 9:27 AM, Christoph Becker cmbecke...@gmx.de wrote:
On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
PHP types are not machine native types. But yes, it forces PHP type -
that's why it is *type* check.
Type hint
On 30/04/2015 02:24, Yasuo Ohgaki wrote:
Type hints have never been hints. The wording is a misnomer. Try to
pass an int to a parameter declared as array, for instance.
I understand how it worked and how it will.
hint sounds a little misleading. Since we named it already, we may follow
the
Hi Rowan,
On Thu, Apr 30, 2015 at 11:00 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 30/04/2015 02:24, Yasuo Ohgaki wrote:
Type hints have never been hints. The wording is a misnomer. Try to
pass an int to a parameter declared as array, for instance.
I understand how it worked
On 30 April 2015 at 02:17, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Current PHP: Search query failure.
New PHP type hint: Fatal error because foreign key is out of PHP int range.
There may be some confusion; NikiC is still doing some work to tidy up
the EngineExceptions. When that is finished
Hi Stas,
On Thu, Apr 30, 2015 at 9:20 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
If you need to force to map value to PHP type, you have strict mode.
Weak
mode is just too strict currently even if PHP handled int/float/string as
integer/float including invalid values
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
A fatal error wouldn't constitute a DoS vulnerability, would it?
Attacker may inject huge ID value and/or they may simply access
web sites to reach 2 billion limit, for example.
That's not a DoS vector
On Wed, Apr 29, 2015 at 7:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
A fatal error wouldn't constitute a DoS vulnerability, would it?
Attacker may inject huge ID value and/or they may simply access
Hi!
How many of us are expected that
mydb_find_by_id(INT_MAX+1);
Note: INT_MAX+1 is pseudo integer string value.
fails with fatal error? I guess it's not many.
I'm not sure what is the meaning of INT_MAX+1 is pseudo integer string
value - if it fits the integer, it's the integer, if it's
Hi Stas,
On Thu, Apr 30, 2015 at 12:05 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
How many of us are expected that
mydb_find_by_id(INT_MAX+1);
Note: INT_MAX+1 is pseudo integer string value.
fails with fatal error? I guess it's not many.
I'm not sure what is the meaning of
Hi!
int Cast is bad. Incorrect int type hint worse as it could trigger DoS.
I do not see any potential for DoS here. Trying to assign security
implications so it looks like disagreeing with you jeopardizes security
is not a good idea. If your code accepts non-numeric data and puts it to
Ryan,
On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas derokor...@gmail.com wrote:
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
A fatal error wouldn't constitute a DoS
On Wed, Apr 29, 2015 at 3:57 PM, Anatol Belski anatol@belski.net
wrote:
On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote:
On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski anatol@belski.net
wrote:
Hi,
On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote:
bumping the thread
On Wed, Apr 29, 2015 at 9:33 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Walter,
On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker walt...@gmail.com wrote:
Are you asking to have both the 32 and 64 bit versions of PHP fully map
to the type system in SQLite? The type system in SQLite appears
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
A fatal error wouldn't constitute a DoS vulnerability, would it?
Attacker may inject huge ID value and/or they may simply access
Hi Walter,
On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker walt...@gmail.com wrote:
Are you asking to have both the 32 and 64 bit versions of PHP fully map to
the type system in SQLite? The type system in SQLite appears to have been
setup to map to programming language that lots of types
Dan,
On Thu, Apr 30, 2015 at 12:02 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 30 April 2015 at 02:17, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Current PHP: Search query failure.
New PHP type hint: Fatal error because foreign key is out of PHP int
range.
There may be some confusion;
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for 7.1
That means introducing a change in 7.0, changing it and deprecating
part of it in 7.1, and removing said part in
60 matches
Mail list logo
