Hi Arvids,
On Thu, Apr 30, 2015 at 3:40 PM, Arvids Godjuks
wrote:
> Stop trying to fix clever idiots from shooting themselves in the foot. The
>> standard result from these actions is to make life a pain for regular or
>> better programmers while only adding mild speed bumps to those clever
>> i
On Wed, Apr 29, 2015 at 11:47 PM, Yasuo Ohgaki wrote:
> Hi Walter,
>
> On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker wrote:
>
>> And that is relevant how? How many Android phone run PHP applications?
>
>
> Search web for IoT devices that can run PHP.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...
Hi!
> Unfortunately, not all users does this and new PHP type hint opens new hole
> that security researchers and attackers are interested in.
I am sorry, but you still brought no proof at all that there are any
security implications. Without such proof, these claims are baseless, so
I intend to
On Wed, Apr 29, 2015 at 11:40 PM, Arvids Godjuks
wrote:
> Stop trying to fix clever idiots from shooting themselves in the foot. The
>> standard result from these actions is to make life a pain for regular or
>> better programmers while only adding mild speed bumps to those clever
>> idiots.
>>
>
Hi Walter,
On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker wrote:
> And that is relevant how? How many Android phone run PHP applications?
Search web for IoT devices that can run PHP.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Stas,
On Thu, Apr 30, 2015 at 2:42 PM, Stanislav Malyshev
wrote:
> > "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
>
>
> Stop trying to fix clever idiots from shooting themselves in the foot. The
> standard result from these actions is to make life a pain for regular or
> better programmers while only adding mild speed bumps to those clever
> idiots.
>
> Things like a numeric type will only encourage the clever i
On Wed, Apr 29, 2015 at 10:50 PM, Yasuo Ohgaki wrote:
> Ryan,
>
> On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas wrote:
>
> > On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki
> wrote:
> >
> >> Hi Rowan,
> >>
> >> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki
> >> wrote:
> >>
> >> >
> >> >> A fata
On Wed, Apr 29, 2015 at 10:42 PM, Stanislav Malyshev
wrote:
> 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
>
Ryan,
On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas wrote:
> On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki wrote:
>
>> Hi Rowan,
>>
>> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki
>> wrote:
>>
>> >
>> >> A fatal error wouldn't constitute a DoS vulnerability, would it?
>>
>> Attack
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
fun
Hi Stas,
On Thu, Apr 30, 2015 at 12:05 PM, Stanislav Malyshev
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 "INT_MA
On Wed, Apr 29, 2015 at 9:33 PM, Yasuo Ohgaki wrote:
> Hi Walter,
>
> On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker 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 ma
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 7.2/8
Dan,
On Thu, Apr 30, 2015 at 12:02 PM, Dan Ackroyd
wrote:
> On 30 April 2015 at 02:17, Yasuo Ohgaki 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
Hi Walter,
On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker 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 (modern C, C++,
> m
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki wrote:
> Hi Rowan,
>
> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki 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 t
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,
On 30 April 2015 at 02:17, Yasuo Ohgaki 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 passing a variable o
On Wed, Apr 29, 2015 at 7:37 PM, Yasuo Ohgaki wrote:
> Hi Rowan,
>
> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki 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 t
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki 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
Hi Rowan,
On Thu, Apr 30, 2015 at 11:00 AM, Rowan Collins
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 and how it
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
th
Hi Christoph,
On Thu, Apr 30, 2015 at 9:27 AM, Christoph Becker wrote:
> > On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev >
> > 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 "
Hi Stas,
On Thu, Apr 30, 2015 at 9:20 AM, Stanislav Malyshev
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 traditionally.
>
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
https://wiki.php.ne
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
exte
Yasuo Ohgaki wrote:
> On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev
> 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 hints. T
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 b
Hi Nathan,
On Thu, Apr 30, 2015 at 6:41 AM, Nathan Bruer 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 a user to
> defin
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
valu
On Thu, Apr 30, 2015 at 2:45 AM, Leigh wrote:
>
> On 29 April 2015 at 14:21, Anatol Belski 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
hi Julien.
On Wed, Apr 29, 2015 at 10:50 PM, Julien Pauli wrote:
> On Wed, Apr 29, 2015 at 3:57 PM, Anatol Belski
> wrote:
>>
>> On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote:
>> > On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski
>> > wrote:
>> >
>> >
>> >> Hi,
>> >>
>> >>
>> >> On Sun, April
Hi Stas,
On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev
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 going to h
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 s
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!
> 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!
> 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
Hi Christoph,
On Thu, Apr 30, 2015 at 7:10 AM, Christoph Becker wrote:
> Yasuo Ohgaki wrote:
>
> > On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker
> wrote:
> >
> >> A solution for this issue has been proposed by the "Big Integer Support"
> >> RFC which has been withdrawn. It's too late for P
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 lessio
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
| thei
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.
Hi Yasuo,
Yasuo Ohgaki wrote:
> On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker 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 PHP 7.1.
>
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
"cle
Hi Christoph,
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker wrote:
> > On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas
> 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_
Hi Francois,
On Thu, Apr 30, 2015 at 6:23 AM, Yasuo Ohgaki 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 weak/strict type hin
Yasuo Ohgaki wrote:
> On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas 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 method that y
Hi Francois,
On Wed, Apr 29, 2015 at 7:03 PM, François Laupretre
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
> > handle
Hi Stas and Ryan,
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas 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 wha
On 29 April 2015 at 14:21, Anatol Belski 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.
> Possibly it could come t
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 Dev
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
wrote:
> Hi
> Found this while trying to do the documentation, Thought the same that it
> was a RFC mistake,
> therefore didn't put any examples. Will d
On Wed, Apr 29, 2015 at 3:57 PM, Anatol Belski
wrote:
> On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote:
> > On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski
> > wrote:
> >
> >
> >> Hi,
> >>
> >>
> >> On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote:
> >>
> >>> bumping the thread as we should st
Sounds good too :)
Three will have plenty to do very soon
On Apr 29, 2015 8:35 PM, "Ferenc Kovacs" wrote:
>
>
> On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski
> wrote:
>
>> Hi,
>>
>> On Sun, April 5, 2015 09:05, Ferenc Kovacs wrote:
>> > bumping the thread as we should start the release steps (
On Wed, April 29, 2015 15:35, Ferenc Kovacs wrote:
> On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski
> 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 m
On Wed, Apr 29, 2015 at 3:21 PM, Anatol Belski
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
> > https://wiki.php.net/
On Apr 29, 2015 8:11 PM, "Zeev Suraski" 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;
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
> -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] I
> 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 targettin
Le mer. 29 avr. 2015 à 10:57, Kalle Sommer Nielsen 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" and that
On Wed, Apr 29, 2015 at 12:24 PM, François Laupretre
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 every da
> 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 D
> 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, the
> 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/6
Le mer. 29 avr. 2015 à 03:19, Pierre Joye a écrit :
> On Apr 29, 2015 5:38 AM, "Adam Harvey" wrote:
> >
> > On 28 April 2015 at 15:10, Patrick ALLAERT
> wrote:
> > > Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen a
> écrit :
> > >
> > >> I should probably have been faster at replying, but
Hi Patrick
2015-04-29 0:10 GMT+02:00 Patrick ALLAERT :
> "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 one for
> document
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 learned,
68 matches
Mail list logo