Hi all,
There are too many things that I would like to improve ;)
https://bugs.php.net/bug.php?id=69127
This bug is known fatal bug for session module. I proposed "lazy_destroy"
to fix
this before, but it declined.
I think the name was wrong. With the proposal, session module destories
session
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/
>
Hi Stas,
On Sun, Mar 1, 2015 at 12:32 PM, Stanislav Malyshev
wrote:
> > https://wiki.php.net/rfc/introduce_design_by_contract
> >
> > This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
> > Please comment if you have any for this RFC.
>
> I don't see why the first one needs any v
On 1 March 2015 at 03:32, Stanislav Malyshev wrote:
> I don't see why the first one needs any vote. It is supposed to be
> implemented as an extension, so why not go and implement an extension,
> and put it in PECL, and then propose it for core inclusion, if it proves
> popular?
Agree
> As for t
Hi all,
I made vote only RFC and started discussion for voting
https://wiki.php.net/rfc/introduce_design_by_contract
Please feel free to correct/improve it.
I added note to our RFCs
https://wiki.php.net/rfc/dbc
---
This RFC is part of “Design by Contract Introduction” RFC
https://wiki.php.net/r
Hi!
> Hi all,
>
> https://wiki.php.net/rfc/introduce_design_by_contract
>
> This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
> Please comment if you have any for this RFC.
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why n
Hi all,
https://wiki.php.net/rfc/introduce_design_by_contract
This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
Please comment if you have any for this RFC.
I'll post RFC discussion for actual proposals soon. Please keep discussion
only about how vote should be done.
Thank you
Hi Crypto,
On Sun, Mar 1, 2015 at 3:32 AM, Crypto Compress <
cryptocompr...@googlemail.com> wrote:
> sorry for the late answer. My point is about throwing exceptions
> (assert.exceptions=1). I think it is wrong to allow to change code-flow by
> ini-setting and in current context it is wrong to th
Hi!
> The root cause of the issue here is preciseness of the setting.
> I think you agree that current "allow_url_include=Off" with INI_SYSTEM is
> not precise at all.
It is precise - it's doing exactly what it meant to do, separate local
wrappers from remote ones.
> We need to consider local a
Hi,
Since no more issues appeared on discussion, the voting for the "Context
Sensitive Lexer" is now open. The voting will close in exactly 14 days
counting from now:
RFC: https://wiki.php.net/rfc/context_sensitive_lexer#votes
Since so few people participated on discussions, if you decide to vot
Hi Rowan,
On Sun, Mar 1, 2015 at 3:46 AM, Rowan Collins
wrote:
> On 28/02/2015 02:37, Yasuo Ohgaki wrote:
>
> Hi Rowan,
>
> On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins
> wrote:
>
>> Yasuo Ohgaki wrote on 27/02/2015 03:44:
>>
>>> Hi all,
>>>
>>> This is RFC for removing "allow_url_include" I
Hi Stas,
On Sat, Feb 28, 2015 at 1:53 PM, Stanislav Malyshev
wrote:
> > I have no intention to change current include/require syntax, except
> adding
> > 2nd parameter.
>
> This is a bit misleading since include is not a function, so there's no
> 1st parameter. Instead, it's a syntax construct.
Am 28.02.2015 um 20:08 schrieb Patrick Schaaf:
Am 28.02.2015 19:32 schrieb "Crypto Compress"
mailto:cryptocompr...@googlemail.com>>:
>
> class BankAccount {
> function Add($amount) {
> assert($amount > 0);
> // ... code block ...
> }
> }
>
> Now the programmer implemen
Am 28.02.2015 19:32 schrieb "Crypto Compress" :
>
> class BankAccount {
> function Add($amount) {
> assert($amount > 0);
> // ... code block ...
> }
> }
>
> Now the programmer implementing "code block" to gracefully handle $amount
> 0 has a problem. There is no way to (Unit)
On 28/02/2015 02:37, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins
mailto:rowan.coll...@gmail.com>> wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing "allow_url_include" INI option. [1]
During "Script
VCS Account Rejected: desty rejected by rasmus /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 21.02.2015 um 04:10 schrieb Yasuo Ohgaki:
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
mailto:cryptocompr...@googlemail.com>>
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific environment.
Joe, your
On 28/02/2015 06:48, Joe Watkins wrote:
Morning internals,
This is just a quick note to announce my intention to ready this RFC
for voting next week.
I know I'm a little late maybe, I was real sick most of last week, so
couldn't do anything useful.
A couple of us intend to fix o
On Sat, Feb 28, 2015 at 12:55 AM, Andi Gutmans wrote:
> > On Feb 27, 2015, at 11:36 AM, Anthony Ferrara
> wrote:
> >
> > Dmitry,
> >
> >>> That's not to say there's anything wrong with this approach, nor that
> >>> there isn't a ton we can learn from it. I think it's a fantastic
> >>> research e
On 28/02/15 08:40, François Laupretre wrote:
> My opinion, but that's only mine, is that I would favor deprecating null to
> scalar, even for internal functions. It would add deprecation messages but
> we'd end up with a cleaner code.
null is a very specific 'state' for anybody working with data
On 28/02/15 08:24, François Laupretre wrote:
> Sorry, not a bug. Documentation is clear. You get 'string|false' from
> substr() and send it to a function expecting 'string'. Most languages will
> fail on this. It worked in PHP because of implicit casting from bool to
> string. We just decided to
> De : Damien Tournoud [mailto:d...@damz.org]
>
> But anyway, that's not even the point. The point is that return values that
> "worked" in a world of transparent type-jungling will not work in a world
> of stricter typing checks. Which means that we need:
>
> (1) To accept that for now casting FA
> De : Brian Moon [mailto:br...@moonspot.net]
>
> I agree here with Benjamin. The thing I have wanted in user land for
> years is to be able to build a user land function that worked the way
> internal functions do in terms of type checking without having to build
> my own type checking system. Hav
> De : Damien Tournoud [mailto:d...@damz.org]
>
> All those are due to a bug in substr(), that we see now only thanks to
> proper type identification. There is no reason for substr() to ever return
> a boolean. It really needs to be fix to always return a string.
Sorry, not a bug. Documentation is
> De : Benjamin Eberlei [mailto:kont...@beberlei.de]
>
> Interestingly functions like is_infinite(), is_dir(), is_file() all expect
> correct types like float or string here although from the naming convention
> "is_something" i would expect it says just false on *anything* else (which
> it almost
> De : Benjamin Eberlei [mailto:kont...@beberlei.de]
>
> The funny thing is that the fix for this is:
>
> - substr($image, strrpos($image, "\n") + 1)
> + (string)substr($image, strrpos($image, "\n") + 1)
>
> Which is that sort of casting that is put forward as argument against the
> dual/strict m
26 matches
Mail list logo
