Re: [PHP-DEV] Re: [VOTE] APXS LoadModule Option in configure

[Lester Caine]

Kris Craig wrote:

I'll commit the changes to 5.4 at the earliest opportunity.  I just
realized that the language was somewhat vague as to whether it should be
applied to 5.3 branch or not; I don't really care either way but I'll
probably just go ahead and apply it to both unless anyone has any
objections.


Any reason to change the 'logic' of 5.3 now? Having already been hit by a 5.4 
change that has not been back-ported, some consistency on what is and isn't 
would be helpful, and I don't think there is any point changing this now as most 
people will simply be updating existing set-ups, and we should be recommending 
5.4 for new installations anyway?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Hinting

[Stas Malyshev]

Hi!


https://wiki.php.net/rfc/parameter_type_casting_hints


Just took a look on it - the syntax proposed there is quite ugly and 
rather confusing, I really wouldn't like to have such syntax in PHP.
Also "(int) $foo = “1” will generate an E_COMPILE_ERROR" makes no sense 
to me.

Also, this line:
function test((int) $intParam, (string) $strParam = "foo", (array) 
$array) {}


is not proper PHP code - it contains optional parameter and then 
parameter with no default.


And can we please stop using word "hinting"?
We can call it type conversion, typecasting, type coercion, etc.
http://en.wikipedia.org/wiki/Type_conversion

But I don't see how there's any hinting involved.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Git Migration: Status Update

[Kris Craig]

On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes  wrote:

> On Wed, Mar 7, 2012 at 6:03 AM, Drak  wrote:
>
> > [snip]
> > Forcing pushes to one's own topic branches in one's own fork can be
> > acceptable providing
> > upstream maintainers know before merging (for example squashing some work
> > after peer review), but not to the central repo without some exceptional
> > reason - it could cause chaos otherwise.
>
>
> Gerrit has an interesting take on this, you are free to do whatever you
> like on refs/heads/dev/${username}/* - including force push etc.
>
> Maybe something like this could be useful?
>
> Kiall
>

Again I would just stress that, if people followed a Git branching model
and only made direct commits to feature branches they themselves
create/maintain, this scenario shouldn't be one that's likely to come up.
 Once a feature branch is complete and it's been tested/approved/whatever
(process is important), you simply do a fresh pull of the develop (or, in
this case, version) branch, rebase the feature off of that, then merge it
into the develop branch and do a push.  Using this approach, any merge
conflicts that might arise (such as overwriting work that somebody else
recently contributed) would be caught before anything is pushed.  Instead,
said conflicts are resolved manually and then Git proceeds with the merge.
 This is similar in concept to what Kiall alluded to.

I know I keep promising to draft an RFC for this lol, so I'll make it a
high priority to put together an RFC for a PHP Git branching model sometime
this week[end].

--Kris

Re: [PHP-DEV] Re: Git Migration: Status Update

[Kiall Mac Innes]

On Wed, Mar 7, 2012 at 6:03 AM, Drak  wrote:

> [snip]
> Forcing pushes to one's own topic branches in one's own fork can be
> acceptable providing
> upstream maintainers know before merging (for example squashing some work
> after peer review), but not to the central repo without some exceptional
> reason - it could cause chaos otherwise.


Gerrit has an interesting take on this, you are free to do whatever you
like on refs/heads/dev/${username}/* - including force push etc.

Maybe something like this could be useful?

Kiall

Re: [PHP-DEV] Re: Git Migration: Status Update

[Drak]

On 5 March 2012 03:15, David Soria Parra  wrote:

> No. We will always need to be able to delete branches created, or tags
> (we had situations were we needed to retag, for example). That in
> itself can be used to do a forced push:
>

[snip]


> I am also not a strong believer trying to forbid as much as possible.
> If you have an SVN account you are trusted enough to not just delete
> something that is used. Also thanks to the decentralized model of git
> we all have backups, so we can just recreate it.


Additionally, if someone force pushes a branch overwriting work it can
always be recovered by a sysadmin from the reflog on the remote server.
 It's not a problem.
However I stress, that something is pretty wrong if people are force
pushing branches to the main repo and I'd personally be slapping wrists if
I saw it for any project I oversee.  Forcing pushes to
one's own topic branches in one's own fork can be acceptable providing
upstream maintainers know before merging (for example squashing some work
after peer review), but not to the central repo without some exceptional
reason - it could cause chaos otherwise.

Regards,

Drak

[PHP-DEV] SVN Account Request: huzaifas

[Huzaifa Sidhpurwala]

Accessing php security bug, since i am subscribed to secur...@php.net now


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Hinting

[Matthew Weier O'Phinney]

On 2012-03-06, Anthony Ferrara  wrote:
> My concern is the total lack of talk on-list about it.  It's obviously
> not perfect, but there has been little to no talk on-list about it.
> That is an indication to me that it's not ready or that it won't get
> in if put to a vote...
>
> Thoughts?

I really like the proposal you set forth. I have zero clue what impact
it would have on performance, however, so I'm deferring that discussion
to those who do. 

As a user and framework developer, I'd love to see it in place -- 
casting support at the function/method parameter level would greatly 
simplify a lot of code I write.


> On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick
> wrote:
>> Hi,
>>
>> It got quite around that because we have some RFCs to this where the
>> functionality seems to be defined as the people thought it should be.
>> Otherwise they can raise their hands and write a mail that they want to
>> update the RFC - but as there's no one doing that, I think we're quite
>> close to what we wanted.
>>
>> Take a look at it and feel free to add your ideas in this thread.
>> https://wiki.php.net/rfc/parameter_type_casting_hints
>> https://wiki.php.net/rfc/object_cast_to_types
>>
>> Bye
>> Simon
>>
>> 2012/3/6 Kris Craig 
>>
>>> Wow no offense, but your timing is terrible, Raymond!  We've been going
>>> back and forth on this for the past couple weeks now, though the discussion
>>> has quieted for the moment.
>>>
>>> I would suggest you go through some of the recent posts on Internals.
>>> Right now there basically is no solid consensus on this issue, though some
>>> of us have been working to change that.  But as it stands now, I'm not
>>> aware of any plans to introduce expanded typing of any kind in the
>>> foreseeable future.  And even if we did, I highly doubt it would happen
>>> before PHP 6.
>>>
>>> --Kris
>>>
>>>
>>> On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving  wrote:
>>>
>>> > Hello,
>>> >
>>> > I came across some info on the web that states that scalar type hinting
>>> was
>>> > added to the PHP trunk but it did not make it's way into 5.4 because of
>>> > objections from the community. Will it ever make it's way into 5.5?
>>> >
>>> > I know PHP is considered to be a weak typed language but it should also
>>> be
>>> > about freedom. Freedom for a PHP developer to choose to use scalar type
>>> > hinting whenever he/she sees the need.
>>> >
>>> >
>>> > Best regards,
>>> > __
>>> > Raymond
>>> >
>>>


-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Hinting

[Anthony Ferrara]

John,

On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw  wrote:
> Disclaimer: The following is direct (maybe brutally so). I'm not trying to 
> hurt any feeling or attack, but I'm not pulling punches either. I don't have 
> the energy right now to polish this and make it all nice and gentle, so I'm 
> sorry in advance. I hope you'll look past the directness and be able to get 
> some useful feedback.

Thank you for being candid.  I appreciate straight to the point
replies, as long as they are respectful (which yours was very much
so).  So thank you.  Now, to your points.

> Yes, it was aimless discussion (though some would call it brainstorming). It 
> was ready to move to the next level, which should have been gathering the 
> constraints/requirements/problems into a coherent list to work from. What 
> happened though was that this step was skipped entirely, so now there's been 
> an attempt to write a preliminary spec without gathering the requirements 
> first, which IMO is far worse than any amount of aimless discussion.

With all honesty, I didn't see anything being gathered.  What I saw
was random ideas shot back and forth (with a good bunch ignored in all
the chatter).  There didn't really seem to be one or two clear
directions, but instead at least a dozen directions at the same time.
There was talk about implementing a "scalar" hint, about implementing
strict hints again, about implementing pseudo-casting hints that did
only simple checks, about hints that actually casted, about hints that
threw notices, about hints that threw warnings.

There didn't seem to be anything more than a bunch of people wanting
different things not even paying attention to the other conversation.
Could a spec have been developed from that?  Sure.  Would it have?
I'm not so sure.

So I picked a direction that seemed consistent with as much of it as
possible, and went with it.  I didn't ask anyone to stop other work,
or stop their discussion.  I just saw an opportunity to unify the
conversation around what seemed to be a commonality between the
comversation, and I took it.  If I stepped on anyone's toes, I'm
sorry...

> A good number of issues with the current proposal were raised during the 
> discussion on the mailing list. I don't feel like digging them all up right 
> now, but off the top of my head I remember the following being raised and 
> never saw any consensus for how to resolve them:

I went over the replies to the initial POC thread that I posted
(http://marc.info/?t=13306603721&r=1&w=2) and I'll rebut your
replies.

> - inconsistent syntax (one syntax for scalars, a different one for classes)

This is actually discussed in the RFC, as it is not inconsistent (it's
actually consistent with what the patch tries to achieve).  The syntax
for classes and normal arrays is a strict check, where if the match
fails an error is thrown.  This syntax attempts to distinguish between
that functionality by providing a different syntax altogether.  And
since it's casting the parameters, the syntax feels natural (for that
goal).

> - conflicting syntax (I.E. array vs. (array), RFC simply "allows" this, and 
> ignores the confusion that this will create for users.)

Actually, it doesn't simply allow that.  It did it for a very specific
reason.  "array" is a strict check, and "(array)" is a casting check.
One will fatal if a non-array is passed, and the other will attempt to
convert the parameter to an array.  Very different functionality,
which are both internally consistent with the other syntax...

> - different from the syntax used in the docs

Actually, it's the exact same syntax used for casting in the docs.
It's different from class type hints, because it's intended to be so.
If you don't like it, that's fine.  But it's intentionally different.

> - lack of sufficient function to justify a core change

That's absolutely something to be considered.  However, I see erroring
on invalid casts as a bigger issue not the responsibility of a
**casting** hint patch.  So that's why I mention explicitly in the RFC
and my blog post that solving that problem should be another RFC
(culminating in a series of 3 RFCs that each work together very well
to fill the overall need).

> - chaos surrounding null (to accept and if so to cast or not? Creates a 
> conflict between consistency and implications of the syntax)

That's absolutely a valid concern.  And that's what should be being
discussed, if people really feel that the current implementation is
wrong...

> - conflicts with references (RFC tries to address this by simply disallowing 
> references, which IMO just ignores the need that would have caused this sort 
> of code in the first place.)

Actually, it explicitly disallows references.  This was added because
it was explicitly requested on the list in many discussions (including
the initial one for the POC).  But if you can make a case on why to
implement it, and why it makes sense, then we can add it back.

> There were others, b

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Alan Knowles]

And the first time your network infrastructure has even a tiny hiccup you 
broadcast your database name/username/password to the whole world. Not an 
excellent business decision.
I've yet to see a php notice / warning echo out a name/password etc...   
- anyway these are normally not public services... - no big deal.


Here's the reality, bugs exist, Users find them.. Users are really 
really bad at describing and reporting them "It does not work"... I can 
take 3-4 rounds (and a few days) of back and forth before you actually 
discover what the real problem is, it wastes their time (and annoys 
them) and yours.. Where as now. they report a screenshot or pasted 
error.. the problem is fixed in minutes.. with the line number and file 
of where the problem is Client is very happy, and pays quicker ;)


Actually this impression that the group espouses 'do not have display 
errors on in production' does not apply to all situations, it may be 
good for your new dotcom super site, but for applications that have to 
work correctly and run business operations, the value proposition can be 
the other way round.



Configuring the server to mail error logs to you isn't hard. The end result is 
actually faster and more reliable than waiting for a user to care enough to 
email you about a problem they see.
Reminds me of the backup emails, you set up warnings for the backup 
failing, but when the server fails, you find out the backup emails 
failed months ago Or you send out a daily backup email and everyone 
learns to ignore it.. It's a nice idea, but only sending me 
warnings/errors on this directory but not the other one and make sure it 
get's sent even if there is a fatal error.. get's complicated quickly. 
KISS is what tends to works here.

Did anyone actually argue about the downsides of this?
Basically the cons come down to old generating more non-fatal errors than it 
did before. This is a minor BC break roughly on par with plenty of other small 
breaks introduced in 5.4.

I do see something important in all this though. I think the documentation 
should explicitly state that E_ALL means absolutely everything, now and 
forever. We got into this mess in the first place because people didn't want to 
change the meaning of E_ALL when E_STRICT was added. We're redefining E_ALL now 
to include E_STRICT, so it means all again, but I think we need a future 
compatible definition that clarifies that this means all present errors, PLUS 
any future errors that get added for any reason. This way adding new error 
types would not need to be considered a BC break.
It is a minor BC break, when you spend an hour clearing up the mess, 
it's not too bad, but I had to ask, was this hour a waste of my time, 
did it help the code quality, and what where the benefits.. I could not 
see any, only the waste of time..


I think the fact is now, that most of the code I work with will have to 
do error_reporting(E_ALL & ~E_STRICT). I'm guessing it's unlikely that 
more error codes will be added that are as valueless as E_STRICT, so I 
think it is something to live with now..., Just in hindsight it may not 
have been a great decision adding it to E_ALL...


Regards
Alan




John Crenshaw
Priacta, Inc.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Scalar Type Hinting

[John Crenshaw]

Disclaimer: The following is direct (maybe brutally so). I'm not trying to hurt 
any feeling or attack, but I'm not pulling punches either. I don't have the 
energy right now to polish this and make it all nice and gentle, so I'm sorry 
in advance. I hope you'll look past the directness and be able to get some 
useful feedback.

> John,
>
> > Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote 
> > consent in this case. I actually basically stopped participating when it 
> > became apparent that people were determined to rush head first into 
> > creating a doomed RFC without any process to ensure that historical 
> > arguments were considered and addressed, with minimal attention to 
> > feedback, and with no concern for syntax (proposed syntax is as bad as the 
> > namespace syntax).
>
> Well, my take on it was that thinking out-loud in a thread is not going to 
> get us anywhere with nothing to base the conversation on.  So I picked an 
> option and proposed it.  As now, we can base the conversation around a real 
> implementation.  Don't like the syntax?
> Great!  Let's find a better solution.  But I felt that it was more important 
> to put a base for the conversation, rather than just letting it wander 
> aimlessly.
>

Yes, it was aimless discussion (though some would call it brainstorming). It 
was ready to move to the next level, which should have been gathering the 
constraints/requirements/problems into a coherent list to work from. What 
happened though was that this step was skipped entirely, so now there's been an 
attempt to write a preliminary spec without gathering the requirements first, 
which IMO is far worse than any amount of aimless discussion.

> > I'm in favor of addressing the type hinting issue, but I'm opposed to this 
> > RFC. It is crippled, confusing, and has a plethora of unaddressed issues.
>
> Then point out the issues.  Help improve it and make it something that
*should* go in the core.  That's why it's still in draft mode.  I didn't 
propose it, or put it for discussion, I put it in draft for that very reason.
>

A good number of issues with the current proposal were raised during the 
discussion on the mailing list. I don't feel like digging them all up right 
now, but off the top of my head I remember the following being raised and never 
saw any consensus for how to resolve them:
- inconsistent syntax (one syntax for scalars, a different one for classes)
- conflicting syntax (I.E. array vs. (array), RFC simply "allows" this, and 
ignores the confusion that this will create for users.)
- different from the syntax used in the docs
- lack of sufficient function to justify a core change
- chaos surrounding null (to accept and if so to cast or not? Creates a 
conflict between consistency and implications of the syntax)
- conflicts with references (RFC tries to address this by simply disallowing 
references, which IMO just ignores the need that would have caused this sort of 
code in the first place.)

There were others, but I'm not making an exhaustive list.

> As far as it being crippled, I'm not sure what you mean, just because it's 
> only doing casting?
>

Yes, casting is barely better than doing nothing. If I want a dumb typecast I 
can do that already. What I can't do without massive boilerplate everywhere is 
an intelligent conversion that accepts safe conversions and gives a warning or 
error on unsafe conversions.

> As far as confusing, it is?  I thought this was actually one of the more 
> straight forward proposals, since it re-used so much from the core (meaning 
> that it doesn't add new behavior, it re-uses existing behavior).
>

Yes, the syntax has some critical issues that create conflicting expectations. 
Look at the prior discussion. The current proposal doesn't really fix most of 
this.

> As far as having a plethora of unadressed issues, I'm absolutely sure it 
> does.  But I haven't seen a single one put out there so that it can be 
> fixed...
>

Again, look at the prior discussion of this syntax. Plenty of issues raised.

> > The object cast has similar problems, and although I recognize the value of 
> > this sort of functionality, the current proposal seems to mostly ignore a 
> > number of critical problems that were raised when it was discussed on the 
> > mailing list.
>
> Which were?  The critical problems that I saw on the list were mostly related 
> to the original proposal wrapping set() with __assign() (which this proposal 
> removed).  The only known issues that I know of that remains is with the 
> __toScalar() part (which in worst case can be removed from the proposal).
>

The biggest one that comes to mind is behavior with respect to operators. 
__toScalar() in your spec is an attempt to handle this, but IMO it really 
doesn't cut it. Off the top of my head problems with this solution include:
- This will lead to duplicated code
- Thinking about my own code, I have almost no idea how I would actually write 
a robust 

[PHP-DEV] Re: [VOTE] APXS LoadModule Option in configure

[Kris Craig]

Voting is now closed.  This RFC was passed unanimously 12-0.

I'll commit the changes to 5.4 at the earliest opportunity.  I just
realized that the language was somewhat vague as to whether it should be
applied to 5.3 branch or not; I don't really care either way but I'll
probably just go ahead and apply it to both unless anyone has any
objections.


Thanks!

--Kris


On Mon, Mar 5, 2012 at 11:24 AM, Kris Craig  wrote:

> FYI-
>
> Voting will be closed at 2 PM (PST) tomorrow.
>
> --Kris
>
>
>
> On Thu, Mar 1, 2012 at 1:04 PM, Kris Craig  wrote:
>
>> Just a friendly reminder to vote on this if you haven't already.  5
>> people have voted on it thus far but I'd like to have at least twice that
>> by the time voting closes.
>>
>> You can read the RFC and vote on it at:
>> https://wiki.php.net/rfc/apxs-loadmodule
>>
>>
>> Thanks!
>>
>> --Kris
>>
>>
>>
>> On Tue, Feb 28, 2012 at 12:19 PM, Kris Craig wrote:
>>
>>> Hi all,
>>>
>>> It looks like we've reached a consensus on this, so absent any
>>> objections, I went ahead and moved this to the voting phase.
>>>
>>> If you're eligible to vote on RFC's, please navigate to the RFC and cast
>>> your vote now:
>>>
>>> https://wiki.php.net/rfc/apxs-loadmodule
>>>
>>>
>>> In case you weren't following the previous thread, this is a very
>>> low-impact RFC that will add a new, optional switch to the configure
>>> script.  This switch, if specified, would tell APXS (which already has this
>>> functionality built-in) not to write the LoadModule line to httpd.conf when
>>> "make install" is performed.  This is a feature that has been requested for
>>> some time and would allow people with manually-built PHP installs to
>>> isolate their mod_php hooks in a separate php.conf file without having to
>>> manually edit httpd.conf whenever a new build is performed.
>>>
>>> If this optional switch is not specified, the configure script will
>>> behave exactly as it does now.  As such, this RFC will *not* alter
>>> configure's existing behavior unless you explicitly include this new switch.
>>>
>>>
>>> Please let me know if you have any last-minute questions.  Otherwise,
>>> happy voting!  Thanks!
>>>
>>> --Kris
>>>
>>>
>>
>

RE: [PHP-DEV] consider reverting E_ALL with E_STRICT

[John Crenshaw]

> - display errors on.
> Yes, this is a business decision, 20 servers running upgraded at different 
> times,
> some have less maintenance others have more.. 
> Seriously, the chance of me even bothering to check one of those log files is
> pretty slim. However if the code is producing warning/notices etc. then that 
> is
> likely hiding a unexpected behavior that the client will report as a bug 
> anyway
> later, so it's proved over many years to be cost effective to have them 
> display,
> clients report problems, and we can fix them.. They kind of like that 
> service
>

And the first time your network infrastructure has even a tiny hiccup you 
broadcast your database name/username/password to the whole world. Not an 
excellent business decision.

Configuring the server to mail error logs to you isn't hard. The end result is 
actually faster and more reliable than waiting for a user to care enough to 
email you about a problem they see.

> ...
>
> Did anyone actually argue about the downsides of this?

Basically the cons come down to old generating more non-fatal errors than it 
did before. This is a minor BC break roughly on par with plenty of other small 
breaks introduced in 5.4.

I do see something important in all this though. I think the documentation 
should explicitly state that E_ALL means absolutely everything, now and 
forever. We got into this mess in the first place because people didn't want to 
change the meaning of E_ALL when E_STRICT was added. We're redefining E_ALL now 
to include E_STRICT, so it means all again, but I think we need a future 
compatible definition that clarifies that this means all present errors, PLUS 
any future errors that get added for any reason. This way adding new error 
types would not need to be considered a BC break.

John Crenshaw
Priacta, Inc.

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Alan Knowles]

Sorry - top post as I can't reply to all the mails on the thread..

- display errors on.
Yes, this is a business decision, 20 servers running upgraded at 
different times, some have less maintenance others have more.. 
Seriously, the chance of me even bothering to check one of those log 
files is pretty slim. However if the code is producing warning/notices 
etc. then that is likely hiding a unexpected behavior that the client 
will report as a bug anyway later, so it's proved over many years to be 
cost effective to have them display, clients report problems, and we can 
fix them.. They kind of like that service


- just email them.
Yes, we could get them emailed to us, but this method has worked for 
years, and is pretty muct failproof, It also adds complexity to a 
simple solution,  for example we run joomla on one server which spews 
crap into the logs (we ignore them as we know what I high quality piece 
of work that is..) however our code installed on the same server does 
not produce a single warning.


If I had a server team, and somebody paid to watch/check  logs etc.. 
display_errors = off would be a recommendation, but this is real life.. 
I do not...


- change in one place
That would be nice, if the client want to run quality software like 
joomla that spews error on the same server as our software, error 
reporting get's turned off in the ini setting, and we always enable it 
for our code in the PHP.


- big vote in favour.
Did anyone actually argue about the downsides of this. On the face of 
the question, let's just add E_STRICT to E_ALL it sounds like it's no 
big deal, I would have probably voted for it, without much thought. It 
sounds like a vote for better code.
But as I discovered yesterday most of the strict errors are pedantic and 
completely pointless to fix, even if I did not have display errors on, 
they would have added a huge amount of noise to log files.


- workaround
for the life of me & ~E_STRICT seemed not to work yesterday.. seems to 
work fine now... oops..


Again, I'll survive, but it's a huge gotcha on upgrading. and should 
probably be promoted to this page.

http://www.php.net/manual/en/migration54.incompatible.php

Regards
Alan

On Wednesday, March 07, 2012 12:22 AM, Gustavo Lopes wrote:
On Tue, 06 Mar 2012 17:08:07 +0100, Alan Knowles  
wrote:



[...]
However with E_STRICT included we have to run around and find all the 
code, and change it to stuff like this:


error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);

Could we please revert that, and if people want an all encompasing 
error mode, call it E_ANAL, like it was supposed to be...


Whatever the merits, this change was discussed and approved 
unanimously with 58 votes in favor (see 
https://wiki.php.net/todo/php54/vote ).
There would have to be a very compelling reason to revert this change, 
especially in a minor version.


Moreover, since you upgraded PHP 5.4, you can also change the global 
php.ini to exclude E_STRICT. If your applications change the error 
reporting level, then, if they are sane, they do it in a centralized 
place, which would also be easy to change.


Plus, it seems odd that you're running with display_errors in 
production. The "users see the errors and report them" seems even 
odder. What a waste of their time. Why don't you just log them? You 
can also automatically send e-mails when these errors occur (e.g. with 
an error handler -- from which, btw, you can exclude E_STRICT errors 
-- or with syslog).





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Hinting

[Anthony Ferrara]

John,

> Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote 
> consent in this case. I actually basically stopped participating when it 
> became apparent that people were determined to rush head first into creating 
> a doomed RFC without any process to ensure that historical arguments were 
> considered and addressed, with minimal attention to feedback, and with no 
> concern for syntax (proposed syntax is as bad as the namespace syntax).

Well, my take on it was that thinking out-loud in a thread is not
going to get us anywhere with nothing to base the conversation on.  So
I picked an option and proposed it.  As now, we can base the
conversation around a real implementation.  Don't like the syntax?
Great!  Let's find a better solution.  But I felt that it was more
important to put a base for the conversation, rather than just letting
it wander aimlessly.

> I'm in favor of addressing the type hinting issue, but I'm opposed to this 
> RFC. It is crippled, confusing, and has a plethora of unaddressed issues.

Then point out the issues.  Help improve it and make it something that
*should* go in the core.  That's why it's still in draft mode.  I
didn't propose it, or put it for discussion, I put it in draft for
that very reason.

As far as it being crippled, I'm not sure what you mean, just because
it's only doing casting?

As far as confusing, it is?  I thought this was actually one of the
more straight forward proposals, since it re-used so much from the
core (meaning that it doesn't add new behavior, it re-uses existing
behavior).

As far as having a plethora of unadressed issues, I'm absolutely sure
it does.  But I haven't seen a single one put out there so that it can
be fixed...

> The object cast has similar problems, and although I recognize the value of 
> this sort of functionality, the current proposal seems to mostly ignore a 
> number of critical problems that were raised when it was discussed on the 
> mailing list.

Which were?  The critical problems that I saw on the list were mostly
related to the original proposal wrapping set() with __assign() (which
this proposal removed).  The only known issues that I know of that
remains is with the __toScalar() part (which in worst case can be
removed from the proposal).



These are RFCs.  I am (as their author) explicitly asking for your
comments and contribution.  They are not set in stone in the least...
In fact, the only way they would get to the point where I would
propose them is with enough input and overview that it was mature.
They are not mature now.

Can we make them mature?

Thanks,

Anthony

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Scalar Type Hinting

[John Crenshaw]

> Hi,
>
> It got quite around that because we have some RFCs to this where the 
> functionality seems to be defined as the people thought it should be.
Otherwise they can raise their hands and write a mail that they want to update 
the RFC - but as there's no one doing that, I think we're quite close to what 
we wanted.
>
> Take a look at it and feel free to add your ideas in this thread.
> https://wiki.php.net/rfc/parameter_type_casting_hints
> https://wiki.php.net/rfc/object_cast_to_types
>
> Bye
> Simon

Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote 
consent in this case. I actually basically stopped participating when it became 
apparent that people were determined to rush head first into creating a doomed 
RFC without any process to ensure that historical arguments were considered and 
addressed, with minimal attention to feedback, and with no concern for syntax 
(proposed syntax is as bad as the namespace syntax).

I'm in favor of addressing the type hinting issue, but I'm opposed to this RFC. 
It is crippled, confusing, and has a plethora of unaddressed issues. The object 
cast has similar problems, and although I recognize the value of this sort of 
functionality, the current proposal seems to mostly ignore a number of critical 
problems that were raised when it was discussed on the mailing list.

John Crenshaw
Priacta, Inc.

Re: [PHP-DEV] Scalar Type Hinting

[Kris Craig]

Personally, speaking for myself at least, I've quieted on the subject
temporarily in favor of advocating some improvements to the RFC voting
process that will ultimately make it easier for us to work through these
type hinting questions.  I'll be resurrecting the discussion on this end
before too long.  =)

--Kris


On Tue, Mar 6, 2012 at 3:35 PM, Anthony Ferrara  wrote:

> My concern is the total lack of talk on-list about it.  It's obviously
> not perfect, but there has been little to no talk on-list about it.
> That is an indication to me that it's not ready or that it won't get
> in if put to a vote...
>
> Thoughts?
>
> Anthony
>
> On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick
>  wrote:
> > Hi,
> >
> > It got quite around that because we have some RFCs to this where the
> > functionality seems to be defined as the people thought it should be.
> > Otherwise they can raise their hands and write a mail that they want to
> > update the RFC - but as there's no one doing that, I think we're quite
> > close to what we wanted.
> >
> > Take a look at it and feel free to add your ideas in this thread.
> > https://wiki.php.net/rfc/parameter_type_casting_hints
> > https://wiki.php.net/rfc/object_cast_to_types
> >
> > Bye
> > Simon
> >
> > 2012/3/6 Kris Craig 
> >
> >> Wow no offense, but your timing is terrible, Raymond!  We've been going
> >> back and forth on this for the past couple weeks now, though the
> discussion
> >> has quieted for the moment.
> >>
> >> I would suggest you go through some of the recent posts on Internals.
> >> Right now there basically is no solid consensus on this issue, though
> some
> >> of us have been working to change that.  But as it stands now, I'm not
> >> aware of any plans to introduce expanded typing of any kind in the
> >> foreseeable future.  And even if we did, I highly doubt it would happen
> >> before PHP 6.
> >>
> >> --Kris
> >>
> >>
> >> On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving 
> wrote:
> >>
> >> > Hello,
> >> >
> >> > I came across some info on the web that states that scalar type
> hinting
> >> was
> >> > added to the PHP trunk but it did not make it's way into 5.4 because
> of
> >> > objections from the community. Will it ever make it's way into 5.5?
> >> >
> >> > I know PHP is considered to be a weak typed language but it should
> also
> >> be
> >> > about freedom. Freedom for a PHP developer to choose to use scalar
> type
> >> > hinting whenever he/she sees the need.
> >> >
> >> >
> >> > Best regards,
> >> > __
> >> > Raymond
> >> >
> >>
>

Re: [PHP-DEV] Scalar Type Hinting

[Anthony Ferrara]

My concern is the total lack of talk on-list about it.  It's obviously
not perfect, but there has been little to no talk on-list about it.
That is an indication to me that it's not ready or that it won't get
in if put to a vote...

Thoughts?

Anthony

On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick
 wrote:
> Hi,
>
> It got quite around that because we have some RFCs to this where the
> functionality seems to be defined as the people thought it should be.
> Otherwise they can raise their hands and write a mail that they want to
> update the RFC - but as there's no one doing that, I think we're quite
> close to what we wanted.
>
> Take a look at it and feel free to add your ideas in this thread.
> https://wiki.php.net/rfc/parameter_type_casting_hints
> https://wiki.php.net/rfc/object_cast_to_types
>
> Bye
> Simon
>
> 2012/3/6 Kris Craig 
>
>> Wow no offense, but your timing is terrible, Raymond!  We've been going
>> back and forth on this for the past couple weeks now, though the discussion
>> has quieted for the moment.
>>
>> I would suggest you go through some of the recent posts on Internals.
>> Right now there basically is no solid consensus on this issue, though some
>> of us have been working to change that.  But as it stands now, I'm not
>> aware of any plans to introduce expanded typing of any kind in the
>> foreseeable future.  And even if we did, I highly doubt it would happen
>> before PHP 6.
>>
>> --Kris
>>
>>
>> On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving  wrote:
>>
>> > Hello,
>> >
>> > I came across some info on the web that states that scalar type hinting
>> was
>> > added to the PHP trunk but it did not make it's way into 5.4 because of
>> > objections from the community. Will it ever make it's way into 5.5?
>> >
>> > I know PHP is considered to be a weak typed language but it should also
>> be
>> > about freedom. Freedom for a PHP developer to choose to use scalar type
>> > hinting whenever he/she sees the need.
>> >
>> >
>> > Best regards,
>> > __
>> > Raymond
>> >
>>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Kris Craig]

Do we have any solid data on the performance difference between arithmetic
operations with bcmath and without?  To me, that would be immensely helpful
in framing this.  I like the idea, but the potential performance drag
concerns me.  Knowing exactly how big a drag we're looking at would make it
easier to put this into some sort of context IMHO.

--Kris

Re: [PHP-DEV] '

[Kris Craig]

2012/3/6 Ángel González 

> On 06/03/12 19:36, Kris Craig wrote:
>
> 
>
> >> FIRST:
> >> do NOT top post after get a reply below your text
> >> or how do you imagine that anybody can follow a
> >> thread where answers randomly before and after
> >> the quotet text?
> > Sorry.  Sometimes I forget that there are some people out there who still
> > use legacy non-threaded inboxes.  I would recommend you consider
> switching
> > to Gmail or some other email client/service that supports threaded views.
> > That will make it a lot easier for you to follow these threads.  =)
> Threaded MUAs won't help when fragments appear as
> 3
> 1
> 2
> 4
>
> In such cases, the people breaking the thread convention should
> the very least remove all the other content.
> And yes, his MUA does support threading.
>
> 
>

I'll try this one last time:  I don't know what the solution is.  What I do
know is that relying solely on, "people should" is not a smart approach
because people are going to break that convention regardless of whether
they should or not.  Yes, educating people is important, but that in and of
itself isn't working.  It doesn't work on any similar listserv I've
subscribed to over the years.  It just seems a bit naive to think that we
can keep repeating the same pattern over and over and expect a different
result.  What I'm suggesting is that it would be to our benefit to think of
a more sustainable approach.  I'm not saying I know what that approach is,
mind you.


>
>
> > To clarify again, I was under the mistaken impression that  > alias for short_open_tag.  My argument was (and still is) against
> > short_open_tag.  I do see some use in this new echo alias for templating
> > purposes.
> >
> > --Kris
> 
>
And your point is?  I initially thought this thread was saying that
this alias had been removed and instead made to replace the
short_open_tag.  I stood corrected and we moved on.  What does PHP 3 have
to do with any of this?  I think you've officially crossed the line from
correcting somebody's error to beating a dead horse.  ;P

--Kris

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

[Ángel González]

On 06/03/12 23:08, Michael Morris wrote:
> 2012/3/6 Ángel González :
>> Tagless files interpreted as php is the wrong way to go.
>> I think you should instead propose it as:
>> * A file included in that mode MUST begin with > * ?> is forbidden in such mode unless followed by EOF.
> Ever work with older versions of subversion or vi? (Many editors will
> put a carriage return after the last character of the file). So no,
> you're wrong.  Requiring ?> at EOF would just be stupid.
Good point. I only wanted to restrict, ?> + 
?>\n doesn't produce an empty line, so it's fine

So it'd be either
* No ?>
* ?>
* ?>\n


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Hinting

[Simon Schick]

Hi,

It got quite around that because we have some RFCs to this where the
functionality seems to be defined as the people thought it should be.
Otherwise they can raise their hands and write a mail that they want to
update the RFC - but as there's no one doing that, I think we're quite
close to what we wanted.

Take a look at it and feel free to add your ideas in this thread.
https://wiki.php.net/rfc/parameter_type_casting_hints
https://wiki.php.net/rfc/object_cast_to_types

Bye
Simon

2012/3/6 Kris Craig 

> Wow no offense, but your timing is terrible, Raymond!  We've been going
> back and forth on this for the past couple weeks now, though the discussion
> has quieted for the moment.
>
> I would suggest you go through some of the recent posts on Internals.
> Right now there basically is no solid consensus on this issue, though some
> of us have been working to change that.  But as it stands now, I'm not
> aware of any plans to introduce expanded typing of any kind in the
> foreseeable future.  And even if we did, I highly doubt it would happen
> before PHP 6.
>
> --Kris
>
>
> On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving  wrote:
>
> > Hello,
> >
> > I came across some info on the web that states that scalar type hinting
> was
> > added to the PHP trunk but it did not make it's way into 5.4 because of
> > objections from the community. Will it ever make it's way into 5.5?
> >
> > I know PHP is considered to be a weak typed language but it should also
> be
> > about freedom. Freedom for a PHP developer to choose to use scalar type
> > hinting whenever he/she sees the need.
> >
> >
> > Best regards,
> > __
> > Raymond
> >
>

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Adam Jon Richardson]

2012/3/6 Ángel González 

> On 06/03/12 14:04, Adam Jon Richardson wrote:
> > The sandbox I'm considering would only impact the ability to directly
> call...
> It's not that easy. The internal functions could be splitted to
> safe/unsafe (according
> tosome definition, which would itself be a controversial one)


Yes, perhaps controversial, but using an objective criterion like purity
would aid the effort.


> but all
> functions defined
> outside would be injection candidates, too.


The idea I put forth would only deal with internal functions. Frameworks
and CMS's would still be on-the-hook to validate incoming data and escape
data according to context for all of the functions that they expose to the
plugin/library. And this would still be very beneficial. As framework
developer, I can validate the inputs coming into my API hooks and escape
the outputs according to context. However, when plugin developers can call
the internal functions and circumvent my protections, this is a more
difficult issue to solve en masse.


> Suppose you modified the
> function
> hash table to store if it's a limited function or it should be run with
> high privileges.
>

I'm not promoting a privilege-based system of high and low privileges.
Rather, I'm posing the possibility of limiting the access of included code
to internal functions/objects.


> Now, you need to audit the whole framework so that no can be tricked
> into doing more
> things than it should, if called from low-privilege code.
> Which is pretty hard when that code could be corrupting your variables.
> For instance, a safe framework function to perform database queries,
> could become
> unsafe by changing the db configuration (usually stored on globals),
> allowing connections
> to arbitrary servers.
>

It would be the responsibility of the framework or CMS or application to
protect against this type of attack (which they do quite well.) When you
can force a plugin to work through your API, you can take appropriate
measures. When the plugin can avoid working through, say, a file API that
protects against misuse by using the internal file functions, this is a
much more difficult issue to mitigate.


> Or a malicious plugin could register a class with the same name as a
> framework one, before
> the autoloader loads the right one, and have it used by privileged code.
>
> PHP is not designed to use it that way, so unless there is an high level
> way to do it, it's probably
> impossible to do right. Maybe you can perform a full global replacement
> when calling
> untrusted code. That might work.
>

Javascript wasn't "designed this way", either. However, tools like Secure
EcmaScript go a long way towards protecting against the attacks mashups
typically must prevent by protecting/limiting the environment:

http://code.google.com/p/es-lab/wiki/SecureEcmaScript
http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5

Thanks for the feedback, Angel.

Adam

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Derick Rethans]

On Tue, 6 Mar 2012, Michael Morris wrote:

> https://wiki.php.net/rfc/php_ini_bcmath_default
> 
> This is the only other RFC I've been rummaging around in my head but
> hadn't brought up.

I know Scott has/had a patch for a special big num type that uses 
bcmath. But don't know what's the status. Scott?

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Tom Boutell]

Excellent idea. bcmath is already not the highest performance thing in
the world, so adding a function that parses a more reasonable looking
expression would not be an unacceptable compromise for most.

It also doesn't give you the false impression that since operators do
the right thing functions are going to do the right thing too. That's
very muddy and confusing.

On Tue, Mar 6, 2012 at 5:12 PM, Daniel Macedo  wrote:
> On Tue, Mar 6, 2012 at 22:05, Michael Morris  wrote:
>> I do use it.  It's a pain in the ass to read because you have to LISP
>> nest all the operations.  You can't tell me this is easy or intuitive
>> to read...
>>
>> bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul(
>> $bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 )
>>
>> Compared to
>>
>> $bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty *
>> $monthsAhead;
>>
>> You can do it, but it's eye bleeding.
>
> I agree with you, how about having the bcmath extension support a more
> general (and even better, non-BC-breaking) function supporting the
> order of math operations (and maybe even math functions)... Something
> like a bc(string $operations [, int $scale = 2])
>
> Supporting passing: bc("(29.99 + $a) * $b - pow(10, $c) / 2");
>
> Came across something like that in the manual: http://php.net/ref.bc#107014
> How's that for a quick 'n dirty idea to solve this issue?
>
> ~ Daniel Macedo
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Daniel Macedo]

On Tue, Mar 6, 2012 at 22:05, Michael Morris  wrote:
> I do use it.  It's a pain in the ass to read because you have to LISP
> nest all the operations.  You can't tell me this is easy or intuitive
> to read...
>
> bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul(
> $bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 )
>
> Compared to
>
> $bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty *
> $monthsAhead;
>
> You can do it, but it's eye bleeding.

I agree with you, how about having the bcmath extension support a more
general (and even better, non-BC-breaking) function supporting the
order of math operations (and maybe even math functions)... Something
like a bc(string $operations [, int $scale = 2])

Supporting passing: bc("(29.99 + $a) * $b - pow(10, $c) / 2");

Came across something like that in the manual: http://php.net/ref.bc#107014
How's that for a quick 'n dirty idea to solve this issue?

~ Daniel Macedo

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

[Michael Morris]

2012/3/6 Ángel González :

> Tagless files interpreted as php is the wrong way to go.
> I think you should instead propose it as:
> * A file included in that mode MUST begin with  * ?> is forbidden in such mode unless followed by EOF.
>
>

Ever work with older versions of subversion or vi? (Many editors will
put a carriage return after the last character of the file). So no,
you're wrong.  Requiring ?> at EOF would just be stupid.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Michael Morris]

On Tue, Mar 6, 2012 at 4:47 PM, Tomas Kuliavas
 wrote:
> 2012.03.06 23:03 Michael Morris rašė:
>> https://wiki.php.net/rfc/php_ini_bcmath_default
>>
>> This is the only other RFC I've been rummaging around in my head but
>> hadn't brought up.
>
> PHP has something similar with mbstring function overloading. If people
> use both string and mbstring functions, they can no longer trust string
> functions. mbstring function overloading makes string functions
> unreliable. Functions, that are not charset aware by default, can start
> operating in different charset with a single flip in interpreter config.
> First you start cursing, then you have to implement workarounds to deal
> with features designed for people, who want to use different functions
> without changing a single line in their code. You are asking to do same
> thing in math functions.

No, I am not.  This RFC involves the operators, not the functions.
Addition, division, multiplication, subtraction.  The PHP math
functions will behave as they always have.

>
> If you want to use bcmath, use bcmath in your code.

I do use it.  It's a pain in the ass to read because you have to LISP
nest all the operations.  You can't tell me this is easy or intuitive
to read...

bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul(
$bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 )

Compared to

$bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty *
$monthsAhead;

You can do it, but it's eye bleeding.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Daniel Macedo]

Michael, I'm with Anthony, in that you shouldn't change behaviour of
this nature with an ini setting.
I would bring more pain than what it takes away.

This is one of those gotchas that everyone comes across, like you noted.
The main issue is that floating point arithmetic != real number
arithmetic; and bc functions do solve the issue, but make for some
ugly code in complex operations...

Since Anthony mentioned Python, maybe the discussion should be if PHP
should/could support decimal like Python does
http://docs.python.org/library/decimal
Now that would be something interesting to see discussed!!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Pierre Joye]

hi Michael,

Nice idea but technically impossible to implement without massive
performance loss.

There was an idea to actually replace the math ops with MPIR
implementation, but tightly integrated. That's something that could be
very good to have. However it is a huge task.

Cheers,

On Tue, Mar 6, 2012 at 10:03 PM, Michael Morris  wrote:
> https://wiki.php.net/rfc/php_ini_bcmath_default
>
> This is the only other RFC I've been rummaging around in my head but
> hadn't brought up.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

[Ángel González]

On 06/03/12 15:45, Michael Morris wrote:
> I have made a wiki account with user name MichaelMorris - I don't
> think I have permissions to submit an RFC as of yet.  I'll post this
> here for now.  I've brought this up before, but can now simplify the
> original proposal since the decision to always have  addresses much of the original problem.
>
> These changes apply to include, require, include_once and
> require_once. Two new arguments for these functions are proposed for
> introduction.
>
> (...)
>
> Problems
> The largest problem is with IDE's. There is no current convention to
> warn them that the file is pure PHP.  However, I think this can be
> mitigated by adopting an extension for php include files -- *.pif,
> *.iphp are two possibilities.  The language itself doesn't need to
> give a care about this directly.
Tagless files interpreted as php is the wrong way to go.
I think you should instead propose it as:
* A file included in that mode MUST begin with  is forbidden in such mode unless followed by EOF.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Tomas Kuliavas]

2012.03.06 23:03 Michael Morris rašė:
> https://wiki.php.net/rfc/php_ini_bcmath_default
>
> This is the only other RFC I've been rummaging around in my head but
> hadn't brought up.

PHP has something similar with mbstring function overloading. If people
use both string and mbstring functions, they can no longer trust string
functions. mbstring function overloading makes string functions
unreliable. Functions, that are not charset aware by default, can start
operating in different charset with a single flip in interpreter config.
First you start cursing, then you have to implement workarounds to deal
with features designed for people, who want to use different functions
without changing a single line in their code. You are asking to do same
thing in math functions.

If you want to use bcmath, use bcmath in your code.

-- 
Tomas


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Ángel González]

On 06/03/12 19:36, Kris Craig wrote:



>> FIRST:
>> do NOT top post after get a reply below your text
>> or how do you imagine that anybody can follow a
>> thread where answers randomly before and after
>> the quotet text?
> Sorry.  Sometimes I forget that there are some people out there who still
> use legacy non-threaded inboxes.  I would recommend you consider switching
> to Gmail or some other email client/service that supports threaded views.
> That will make it a lot easier for you to follow these threads.  =)
Threaded MUAs won't help when fragments appear as
3
1
2
4

In such cases, the people breaking the thread convention should
the very least remove all the other content.
And yes, his MUA does support threading.




> To clarify again, I was under the mistaken impression that  alias for short_open_tag.  My argument was (and still is) against
> short_open_tag.  I do see some use in this new echo alias for templating
> purposes.
>
> --Kris
http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Michael Morris]

On Tue, Mar 6, 2012 at 4:31 PM, Anthony Ferrara  wrote:

>
> Actually, I see that as even worse.  Why would 2 * 4 be possible to be
> different from pow(2, 3)?  That doesn't really make sense (to me).  I
> think if it was added, all of the math related extensions would need
> to be (should be) updated as suits.  Otherwise it's just another
> random inconsistency...

The problem is that not all the math functions have BCmath
equivalents. Bit of scope creep here if that is to be done.

>
>
> When I said BC break, I'm talking about at the engine level.  So all
> 3pd code that hooks into the engine (PECL extensions mainly) would be
> broken, as the structure of the ZVal would need to change to
> accommodate the bignum representation...

BCMath returns the value as a string.  I don't know what the
ramification of that inside the engine is, but numbers end up being
held as strings when this is active.

I'm not trying to make light of these problems - they are significant.
 But PHP's current behavior is, to a non-cs major, not intuitive.
I've progressed in my career to where I personally aren't bothered by
this problem, but there are a lot of beginning scripters that can be
caught with this.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Anthony Ferrara]

>> But please don't add another ini setting.  Especially one where
>> *logic* can change depending on the setting.  I don't want a case
>> where pow(2, 65)-1 will return different answers depending on the ini.
>>  That's just asking for problems.
>
> I edited the RFC while you were sending this for clarification. This
> setting would only affect the math operators (+,/,*,-) mapping them to
> their bcmath equivalents.  Math functions like pow would not be
> affected.

Actually, I see that as even worse.  Why would 2 * 4 be possible to be
different from pow(2, 3)?  That doesn't really make sense (to me).  I
think if it was added, all of the math related extensions would need
to be (should be) updated as suits.  Otherwise it's just another
random inconsistency...

>>
>> Instead, perhaps a pythonic approach may be useful (storing as
>> int/float for small values, but auto-converting to arbitrary precision
>> if the int/float can't exactly represent what was
>> requested/computed)...  Just a thought to make it useful without the
>> ini complexity or performance hits.
>>
>> Although this will present a significant BC break (internally, zend
>> engine wise), so it would probably be limited to a major release
>> anyway...
>>
>
> With a setting there would be no BC break since, if you turn it on,
> presumably you want it on.  Also, for scripts where the author wasn't
> aware of the peril of floating point math the setting could actually
> fix their existing code.

When I said BC break, I'm talking about at the engine level.  So all
3pd code that hooks into the engine (PECL extensions mainly) would be
broken, as the structure of the ZVal would need to change to
accommodate the bignum representation...

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Ángel González]

On 06/03/12 17:08, Alan Knowles wrote:
> I just got caught on a production server with the 5.4 upgrade on
> debian, pretty much everything works fine, except the E_ALL change.
>
> I have to admit I missed the discussion where it was added, and
> searching for E_ALL or E_STRICT on marc is pretty difficult (it
> removes the E_ bit..)
>
> Anyway, this change is a bit of an bomb on the code on the first
> server to get hit with this, While i've never cared for E_STRICT (it's
> more like E_ANAL) - most of the warnings are pointless code tidy up's
> that only have pretty much zero cost/return in fixing.
>
> However, this change really kills code written by third parties, All
> our servers run with E_ALL on (eg. E_NOTICE is printed to end users)
> and we fix instantly any errors that the end users see, as they are
> frequently issues that should have been addressed. These applications
> are intra/extranet apps, not public websites.
>
> However with E_STRICT included we have to run around and find all the
> code, and change it to stuff like this:
>
> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);
error_reporting(E_ALL & ~E_STRICT); will work everywhere. You could even
do a global search and replace of E_ALL to (E_ALL & ~E_STRICT), assuming
it never appears in eg. a string.


PS: I also consider E_STRICT a mostly helpful resource, and not using
display_errors on production the sensible thing to do.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Michael Morris]

On Tue, Mar 6, 2012 at 4:18 PM, Anthony Ferrara  wrote:
> I initially like the concept (arbitrary precision operations).
>
> But please don't add another ini setting.  Especially one where
> *logic* can change depending on the setting.  I don't want a case
> where pow(2, 65)-1 will return different answers depending on the ini.
>  That's just asking for problems.

I edited the RFC while you were sending this for clarification. This
setting would only affect the math operators (+,/,*,-) mapping them to
their bcmath equivalents.  Math functions like pow would not be
affected.

>
> Instead, perhaps a pythonic approach may be useful (storing as
> int/float for small values, but auto-converting to arbitrary precision
> if the int/float can't exactly represent what was
> requested/computed)...  Just a thought to make it useful without the
> ini complexity or performance hits.
>
> Although this will present a significant BC break (internally, zend
> engine wise), so it would probably be limited to a major release
> anyway...
>

With a setting there would be no BC break since, if you turn it on,
presumably you want it on.  Also, for scripts where the author wasn't
aware of the peril of floating point math the setting could actually
fix their existing code.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Anthony Ferrara]

I initially like the concept (arbitrary precision operations).

But please don't add another ini setting.  Especially one where
*logic* can change depending on the setting.  I don't want a case
where pow(2, 65)-1 will return different answers depending on the ini.
 That's just asking for problems.

Instead, perhaps a pythonic approach may be useful (storing as
int/float for small values, but auto-converting to arbitrary precision
if the int/float can't exactly represent what was
requested/computed)...  Just a thought to make it useful without the
ini complexity or performance hits.

Although this will present a significant BC break (internally, zend
engine wise), so it would probably be limited to a major release
anyway...

Just a thought...

Anthony

On Tue, Mar 6, 2012 at 4:03 PM, Michael Morris  wrote:
> https://wiki.php.net/rfc/php_ini_bcmath_default
>
> This is the only other RFC I've been rummaging around in my head but
> hadn't brought up.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Ángel González]

On 06/03/12 14:04, Adam Jon Richardson wrote:
> The sandbox I'm considering would only impact the ability to directly call
> internal functions. The idea rests on the hope that the framework or CMS
> provides a security model that protects the integrity of their own
> environment. The framework can for example hand off whatever state
> variables are deemed appropriate and necessary to a plugin. The framework
> can make public whatever methods are appropriate and necessary. However,
> the framework can't currently limit the direct calls to internal functions
> (without parsing the PHP source and it's dependencies), which could allow
> the plugin developer to circumvent the security policies of the framework.
>
> Indeed, the complexity is extreme, even for the limited scope of this idea.
> And, avoiding complexity for the developers using the sandboxed version
> would be difficult, too.
>
> I'm wondering if it would be easier to allow constants representing entire
> classes of functionality. For example:
>
> include_restricted('file/path', $whitelist = array('SANDBOX_FILE',
> 'SANDBOX_PDO', 'SANDBOX_MYSQL', 'SANDBOX_SOCKET'));
>
> If an error was raised because an included file required additional access,
> the error message could detail the exact constant(s) that would have to be
> whitelisted for the include to be allowed.
>
> Thank you for the feedback, Stas. The questions and concerns raised in this
> discussion help considerably.
>
> Adam
It's not that easy. The internal functions could be splitted to
safe/unsafe (according
tosome definition, which would itself be a controversial one) but all
functions defined
outside would be injection candidates, too. Suppose you modified the
function
hash table to store if it's a limited function or it should be run with
high privileges.
Now, you need to audit the whole framework so that no can be tricked
into doing more
things than it should, if called from low-privilege code.
Which is pretty hard when that code could be corrupting your variables.
For instance, a safe framework function to perform database queries,
could become
unsafe by changing the db configuration (usually stored on globals),
allowing connections
to arbitrary servers.
Or a malicious plugin could register a class with the same name as a
framework one, before
the autoloader loads the right one, and have it used by privileged code.

PHP is not designed to use it that way, so unless there is an high level
way to do it, it's probably
impossible to do right. Maybe you can perform a full global replacement
when calling
untrusted code. That might work.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Reindl Harald]

Am 06.03.2012 19:36, schrieb Kris Craig:
> Sorry.  Sometimes I forget that there are some people out there who still
> use legacy non-threaded inboxes.  I would recommend you consider switching
> to Gmail or some other email client/service that supports threaded views.
> That will make it a lot easier for you to follow these threads.  =)

do not argue so silly
no software can fix missing skills

and no thread-view can repair the fact that people get
confused if there is reply-question-reply in random order

and no it is not acceptable to open 5 messages for an
overview of a thread because it is wasted time

if you get an answer below your question put your
answer also below instead telling people which
software they should use only because you are
unable for proper use of the medium e-mail

and no i will surely NOT put my mails to google
since i am mail-admin at my own also i will not
switch any settings in thunderbird or even consider
another mail-client because some random people are
not thinking 2 seconds before they act



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Michael Morris]

https://wiki.php.net/rfc/php_ini_bcmath_default

This is the only other RFC I've been rummaging around in my head but
hadn't brought up.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Kris Craig]

Responses inline per your request.

--Kris


On Tue, Mar 6, 2012 at 3:32 AM, Reindl Harald wrote:

> Am 06.03.2012 01:13, schrieb Kris Craig:
> > On Windows (where I generally do most of my scripting grunt work),
> > I typically use Notepad++ and it highlights
> >  >
> > On Mon, Mar 5, 2012 at 4:11 PM, Reindl Harald 
> >  h.rei...@thelounge.net>> wrote:
> > Am 06.03.2012 01:03, schrieb Kris Craig:
> > > I've never understood the "it's easier to read" argument since
> I've found
> > > it to be exactly the opposite.  The  least for
> > > me, makes it more difficult to "at a glance" see where the PHP
> code begins
> >
> > if you hvae a usebale editor  would become different
> colors
> > only in notepad or on the shell you would not see php-code but
> > who does develop this way these days?
>
> FIRST:
> do NOT top post after get a reply below your text
> or how do you imagine that anybody can follow a
> thread where answers randomly before and after
> the quotet text?
>

Sorry.  Sometimes I forget that there are some people out there who still
use legacy non-threaded inboxes.  I would recommend you consider switching
to Gmail or some other email client/service that supports threaded views.
That will make it a lot easier for you to follow these threads.  =)


>
> SECOND:
> it is simply clear that it highlights " what i said is "throw it away if it does NOT highlight ""
>
> the "" is much easier readable as ""
>
>
>
To clarify again, I was under the mistaken impression that 

Re: [PHP-DEV] 5.3.11 planning

[Johannes Schlüter]

On Tue, 2012-03-06 at 11:19 +, Derick Rethans wrote:
> I'd like to get my simple ZEND_DONT_UNLOAD_MODULES patch in:

Yeah, it's proven and useful. Please also add the part from
README.ZEND_MM.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Stas Malyshev]

Hi!


However, this change really kills code written by third parties, All our
servers run with E_ALL on (eg. E_NOTICE is printed to end users) and we


You run production with display_errors enabled? Please don't do that. 
You have logs for that. Doesn't matter if it's intranet or not, this is 
not the right thing to do.


Besides that, nobody forces anybody to configure error level as E_ALL. 
All means, well, all... If you don't want all, set the error level to 
something else.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

[Michael Morris]

On Tue, Mar 6, 2012 at 11:40 AM, Ferenc Kovacs  wrote:

>
> I don't like this, I mean one can end up printing out his sourcecode if
> - those files are publically available through the document root

This can also occur if the server is mis-configured. That said, one
way to deal with this.  One would be to allow the server itself to
start PHP with the file being loaded as tagless.  In either event
though we're dealing with a config change, and users don't always
remember to do those when they switch versions.

Would current software break though?  I don't think so.  Anyone doing
this would (should?) be aware of the ramifications.  I'm personally
not a fan of putting all the PHP files in the web document root, but I
can understand why its done and I know its the current most common
practice.

> or
> - if he somewhere used a wrong argument, and includes a tagless file with
> the (default) with-tags option.
> on the other hand, a html file page with php code examples (but without php
> tags) could be turned into executing those examples if the tagless option is
> used.

That's actually up in the air as to how this is implemented.  If
implemented such that the parser just appends "

I feel neither example is really a new vulnerability though.  If
anything, it makes code injection a bit trickier. But the basic mode
of exploit isn't going to change.

And the programmer working with this should be able to correct his
mistake and move on.

>
>
> I would support the namespace option though.

Of the two this one is actually the one that scares the heck out me in
terms of what can go wrong if it is misused.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3.11 planning

[Derick Rethans]

On Tue, 6 Mar 2012, Brian J. France wrote:

> Could you explain the use case for this?  Just for my own curiosity, I 
> am sure you have a valid reason for it.
> 
> I have always found that only bad things happen when you let 
> extensions/modules/shared libs stay loaded during the double load of 
> apache.

Well, it's more meant for debugging only (on the command line):
http://drck.me/vlgrnd-shared-8po

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

[Ferenc Kovacs]

>
>
> The first is boolean - whether to look for php tags of any sort in the
> file.  The default needs to be to expect them, this is the backwards
> compatible behavior, and I'm thinking this should be 0.  1 means "no
> tags in file".  This means the file to be included can be written
> without any php tags at all.  This might allow the parser to speed up,
> but that would be a side benefice to two goals.
>

I don't like this, I mean one can end up printing out his sourcecode if
- those files are publically available through the document root
or
- if he somewhere used a wrong argument, and includes a tagless file with
the (default) with-tags option.
on the other hand, a html file page with php code examples (but without php
tags) could be turned into executing those examples if the tagless option
is used.


I would support the namespace option though.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Ferenc Kovacs]

On Tue, Mar 6, 2012 at 5:08 PM, Alan Knowles  wrote:

> I just got caught on a production server with the 5.4 upgrade on debian,
> pretty much everything works fine, except the E_ALL change.
>
> I have to admit I missed the discussion where it was added, and searching
> for E_ALL or E_STRICT on marc is pretty difficult (it removes the E_ bit..)
>
> Anyway, this change is a bit of an bomb on the code on the first server to
> get hit with this, While i've never cared for E_STRICT (it's more like
> E_ANAL) - most of the warnings are pointless code tidy up's that only have
> pretty much zero cost/return in fixing.
>
> However, this change really kills code written by third parties, All our
> servers run with E_ALL on (eg. E_NOTICE is printed to end users) and we fix
> instantly any errors that the end users see, as they are frequently issues
> that should have been addressed. These applications are intra/extranet
> apps, not public websites.
>
> However with E_STRICT included we have to run around and find all the
> code, and change it to stuff like this:
>
> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);
>
> Could we please revert that, and if people want an all encompasing error
> mode, call it E_ANAL, like it was supposed to be...
>
> Regards
> Alan


it was proposed and voted in a "bulk" RFC, see
http://www.mail-archive.com/internals@lists.php.net/msg51887.html
the "Add E_STRICT to E_ALL" won by 58 to 0, so it was heavily supported by
the voters, and that was one of the things that was already decided and
commited in php6:
http://www.mail-archive.com/internals@lists.php.net/msg21822.html
I still think that E_STRICT can only serve it's purpose if our users are
seeing those messages, on a relevant note, also check out this thread from
Stas: http://www.mail-archive.com/internals@lists.php.net/msg52259.html

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Reindl Harald]

Am 06.03.2012 17:22, schrieb Gustavo Lopes:
> On Tue, 06 Mar 2012 17:08:07 +0100, Alan Knowles  wrote:
> 
>> [...]
>> However with E_STRICT included we have to run around and find all the code, 
>> and change it to stuff like this:
>>
>> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);
>>
>> Could we please revert that, and if people want an all encompasing error 
>> mode, call it E_ANAL, like it was
>> supposed to be...
> 
> Whatever the merits, this change was discussed and approved unanimously with 
> 58 votes in favor (see
> https://wiki.php.net/todo/php54/vote ).
> There would have to be a very compelling reason to revert this change, 
> especially in a minor version.

there is no single reason to revert this bugfix
the bugs were in PHP < 5.4 where ALL WAS NOT ALL which is not really smart

the word ALL has a very clear definition



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Daniel Macedo]

PLEASE, don't be the kind of developer that does this all over his code:

>> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);

Either define it once in the same place, or use the php.ini value and
make sure it's proper.
Here's my development/production, yours should be the same:

; Development
display_errors = On
display_startup_errors = On
log_errors = Off
; This can now be E_ALL; as it should!
error_reporting = E_ALL | E_STRICT

; Production
display_errors = Off
display_startup_errors = Off
log_errors = On
ignore_repeated_errors = On
error_log = "/var/logs/php_error_log"
error_reporting = E_ALL & ~E_DEPRECATED

Cheers,
~ Daniel Macedo

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3.11 planning

[Brian J. France]

Could you explain the use case for this?  Just for my own curiosity, I am sure 
you have a valid reason for it.  

I have always found that only bad things happen when you let 
extensions/modules/shared libs stay loaded during the double load of apache.

Thanks!

Brian


On Mar 6, 2012, at 6:19 AM, Derick Rethans wrote:

> On Tue, 6 Mar 2012, Johannes Schlüter wrote:
> 
>> just a quick note on 5.3.11 planning:
>> 
>> We will migrate to git in roughly one week. I'll give it a few days to
>> verify migration works fine afterwards and then start the 5.3.11
>> process. Best is to get outstanding fixes in early. ;-)
> 
> I'd like to get my simple ZEND_DONT_UNLOAD_MODULES patch in:
> 
> Index: Zend/zend_API.c
> ===
> --- Zend/zend_API.c   (revision 322920)
> +++ Zend/zend_API.c   (working copy)
> @@ -2134,7 +2134,7 @@
> 
> #if HAVE_LIBDL
> #if !(defined(NETWARE) && defined(APACHE_1_BUILD))
> - if (module->handle) {
> + if (module->handle && !getenv("ZEND_DONT_UNLOAD_MODULES")) {
>   DL_UNLOAD(module->handle);
>   }
> #endif
> 
> cheers,
> Derick
> 
> -- 
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Gustavo Lopes]

On Tue, 06 Mar 2012 17:08:07 +0100, Alan Knowles  wrote:


[...]
However with E_STRICT included we have to run around and find all the  
code, and change it to stuff like this:


error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);

Could we please revert that, and if people want an all encompasing error  
mode, call it E_ANAL, like it was supposed to be...


Whatever the merits, this change was discussed and approved unanimously  
with 58 votes in favor (see https://wiki.php.net/todo/php54/vote ).
There would have to be a very compelling reason to revert this change,  
especially in a minor version.


Moreover, since you upgraded PHP 5.4, you can also change the global  
php.ini to exclude E_STRICT. If your applications change the error  
reporting level, then, if they are sane, they do it in a centralized  
place, which would also be easy to change.


Plus, it seems odd that you're running with display_errors in production.  
The "users see the errors and report them" seems even odder. What a waste  
of their time. Why don't you just log them? You can also automatically  
send e-mails when these errors occur (e.g. with an error handler -- from  
which, btw, you can exclude E_STRICT errors -- or with syslog).


--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Pierre Joye]

hi Alan!

On a server you are supposed to use logs, not to display errors.

Also if one does not like the default, he can always set  the error
reporting using what he likes to, per directory or globally.

I see no reason to do revert what is actually a good thing. All means
all, not all but this and that.

Cheers,

On Tue, Mar 6, 2012 at 5:08 PM, Alan Knowles  wrote:
> I just got caught on a production server with the 5.4 upgrade on debian,
> pretty much everything works fine, except the E_ALL change.
>
> I have to admit I missed the discussion where it was added, and searching
> for E_ALL or E_STRICT on marc is pretty difficult (it removes the E_ bit..)
>
> Anyway, this change is a bit of an bomb on the code on the first server to
> get hit with this, While i've never cared for E_STRICT (it's more like
> E_ANAL) - most of the warnings are pointless code tidy up's that only have
> pretty much zero cost/return in fixing.
>
> However, this change really kills code written by third parties, All our
> servers run with E_ALL on (eg. E_NOTICE is printed to end users) and we fix
> instantly any errors that the end users see, as they are frequently issues
> that should have been addressed. These applications are intra/extranet apps,
> not public websites.
>
> However with E_STRICT included we have to run around and find all the code,
> and change it to stuff like this:
>
> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);
>
> Could we please revert that, and if people want an all encompasing error
> mode, call it E_ANAL, like it was supposed to be...
>
> Regards
> Alan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Rasmus Lerdorf]

On 03/06/2012 06:03 AM, John Crenshaw wrote:
> I've seen a simple "safe" code evaluator put together using token_get_all. 
> I'm certain that you could create an include_restricted() function in 
> userland using a similar system: walk through the tokens looking for anything 
> forbidden (this will be tricky, because there are a lot of nooks that things 
> could hide, like superglobals), then if everything looks good include the 
> file. Use a caching system of some sort to improve performance and eliminate 
> redundant checks.

Yeah, a token approach wouldn't work. $a = 'mysql_connect'; $a($args);
trivially circumvents that. It would have to build new function/class
hashtables directly which is rather expensive so from a performance
perspective this would not be pretty. I suppose an opcode cache could
cache these to speed this up quite a bit, but there would still need to
be extra gear in place to manage multiple hash tables and some code to
check if there was an overriding hash to be used for every op_array.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

[Reindl Harald]

Am 06.03.2012 17:08, schrieb Alan Knowles:
> However with E_STRICT included we have to run around and find all the code, 
> and 
> change it to stuff like this: error_reporting(E_ALL & E_STRICT ? E_ALL ^ 
> E_STRICT : E_ALL);
> 
> Could we please revert that, and if people want an all encompasing error 
> mode, call it 
> E_ANAL, like it was supposed to be...

since 8 years on all production servers:
error_reporting = E_ALL | E_STRICT

the world would be a better place if code not working
with this is thrown away because any developer is
strongly suggested to use this in development for
find small errors often makeing big problems



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] consider reverting E_ALL with E_STRICT

[Alan Knowles]

I just got caught on a production server with the 5.4 upgrade on debian, 
pretty much everything works fine, except the E_ALL change.


I have to admit I missed the discussion where it was added, and 
searching for E_ALL or E_STRICT on marc is pretty difficult (it removes 
the E_ bit..)


Anyway, this change is a bit of an bomb on the code on the first server 
to get hit with this, While i've never cared for E_STRICT (it's more 
like E_ANAL) - most of the warnings are pointless code tidy up's that 
only have pretty much zero cost/return in fixing.


However, this change really kills code written by third parties, All our 
servers run with E_ALL on (eg. E_NOTICE is printed to end users) and we 
fix instantly any errors that the end users see, as they are frequently 
issues that should have been addressed. These applications are 
intra/extranet apps, not public websites.


However with E_STRICT included we have to run around and find all the 
code, and change it to stuff like this:


error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL);

Could we please revert that, and if people want an all encompasing error 
mode, call it E_ANAL, like it was supposed to be...


Regards
Alan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Namespace and Parse tags on Include and Require

[Michael Morris]

Ok, with Hannes help I have the RFC up now.

https://wiki.php.net/rfc/changes_to_include_and_require

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL

[Ondřej Surý]

On Fri, Mar 2, 2012 at 13:34, Pierre Joye  wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
>
> I'm in favor of option #1, as it gives enough time to our users to
> migrate by reducing the maintenance period to only one year.
>
> Suggestions or comments welcome,

The estimated time for next stable Debian release is the end of this
year. Oldstable security is something between 12-18 months, so I think
I can live with Option #1 (and patches I could cherry-pick from git -
I cannot wait for the migration).

O.
-- 
Ondřej Surý 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

[Hannes Magnusson]

On Tue, Mar 6, 2012 at 15:45, Michael Morris  wrote:
> I have made a wiki account with user name MichaelMorris - I don't
> think I have permissions to submit an RFC as of yet.  I'll post this

You do now.
Things much smother though when you actually read the registration page.
We don't everyone write karma just by registering.

-Hannes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

[Michael Morris]

I have made a wiki account with user name MichaelMorris - I don't
think I have permissions to submit an RFC as of yet.  I'll post this
here for now.  I've brought this up before, but can now simplify the
original proposal since the decision to always have http://www.php.net/unsub.php

RE: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[John Crenshaw]

>> Hi!
>>
>>  Thoughts?
>>>
>>
>> This is a fine idea, however actually doing it is not that easy. Note 
>> that knowing which function is "safe" is pretty hard, but that's only a 
>> start.
>> Plugin code, for example, can call functions outside plugin context, 
>> while passing all kinds of arguments - is it safe or not? It depends 
>> on the context - e.g. plugin may need access to the database - 
>> directly or through some API - but that opens the door to various SQL 
>> injections and other mischief, etc. etc.
>> So while the idea is fine, designing a working sandbox is a very 
>> complicated task. That said, if you have any ideas - you're welcome to 
>> propose.
>
>
> The sandbox I'm considering would only impact the ability to directly call
> internal functions. The idea rests on the hope that the framework or CMS
> provides a security model that protects the integrity of their own
> environment. The framework can for example hand off whatever state
> variables are deemed appropriate and necessary to a plugin. The framework
> can make public whatever methods are appropriate and necessary. However,
> the framework can't currently limit the direct calls to internal functions
> (without parsing the PHP source and it's dependencies), which could allow
> the plugin developer to circumvent the security policies of the framework.
>
> Indeed, the complexity is extreme, even for the limited scope of this idea.
> And, avoiding complexity for the developers using the sandboxed version
> would be difficult, too.
>
> I'm wondering if it would be easier to allow constants representing entire
> classes of functionality. For example:
>
> include_restricted('file/path', $whitelist = array('SANDBOX_FILE',
> 'SANDBOX_PDO', 'SANDBOX_MYSQL', 'SANDBOX_SOCKET'));
>
> If an error was raised because an included file required additional access,
> the error message could detail the exact constant(s) that would have to be
> whitelisted for the include to be allowed.
>
> Thank you for the feedback, Stas. The questions and concerns raised in this
> discussion help considerably.
>
> Adam

I've seen a simple "safe" code evaluator put together using token_get_all. I'm 
certain that you could create an include_restricted() function in userland 
using a similar system: walk through the tokens looking for anything forbidden 
(this will be tricky, because there are a lot of nooks that things could hide, 
like superglobals), then if everything looks good include the file. Use a 
caching system of some sort to improve performance and eliminate redundant 
checks.

I seriously doubt that this would ever get implemented in the core though. PHP 
has been moving away from this sort of thing (and for good reason). Attempting 
a "one size fits all" sandbox in the core just doesn't make any sense.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Adam Jon Richardson]

On Tue, Mar 6, 2012 at 4:38 AM, Stas Malyshev wrote:

> Hi!
>
>  Thoughts?
>>
>
> This is a fine idea, however actually doing it is not that easy. Note that
> knowing which function is "safe" is pretty hard, but that's only a start.
> Plugin code, for example, can call functions outside plugin context, while
> passing all kinds of arguments - is it safe or not? It depends on the
> context - e.g. plugin may need access to the database - directly or through
> some API - but that opens the door to various SQL injections and other
> mischief, etc. etc.
> So while the idea is fine, designing a working sandbox is a very
> complicated task. That said, if you have any ideas - you're welcome to
> propose.


The sandbox I'm considering would only impact the ability to directly call
internal functions. The idea rests on the hope that the framework or CMS
provides a security model that protects the integrity of their own
environment. The framework can for example hand off whatever state
variables are deemed appropriate and necessary to a plugin. The framework
can make public whatever methods are appropriate and necessary. However,
the framework can't currently limit the direct calls to internal functions
(without parsing the PHP source and it's dependencies), which could allow
the plugin developer to circumvent the security policies of the framework.

Indeed, the complexity is extreme, even for the limited scope of this idea.
And, avoiding complexity for the developers using the sandboxed version
would be difficult, too.

I'm wondering if it would be easier to allow constants representing entire
classes of functionality. For example:

include_restricted('file/path', $whitelist = array('SANDBOX_FILE',
'SANDBOX_PDO', 'SANDBOX_MYSQL', 'SANDBOX_SOCKET'));

If an error was raised because an included file required additional access,
the error message could detail the exact constant(s) that would have to be
whitelisted for the include to be allowed.

Thank you for the feedback, Stas. The questions and concerns raised in this
discussion help considerably.

Adam

[PHP-DEV] SVN Account Request: olemarkus

[Ole Markus With]

As per Pierre, required for accessing security bugs/repo etc. 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Adam Jon Richardson]

On Tue, Mar 6, 2012 at 3:30 AM, Florian Anderiasch wrote:

> Isn't that basically what all template engines tried to solve before
> with giving you a defined subset of tokens that are more or less
> directly converted to php code? The benefit I see is that plugin
> developers wouldn't need to learn a new DSL (domain-specific language),
> but use PHP code. Just that it's not PHP if you disable 90% of the
> functions available.
>

I agree, many template engines do offer a controlled set of language
constructs that limit the attack surface. However, DSL's tend to be focused
on one specific problem area (such as templating, as you noted) as opposed
to providing general programming capabilities, so building plugins in a DSL
can be quite limiting in terms of potential power:

http://martinfowler.com/bliki/DomainSpecificLanguage.html

As another option, one could always develop a full-fledge programming
language that compiles down to PHP (similar to CoffeeScript's compiling to
JavaScript.) One can then use the language to abstract away calls to
functions deemed unsafe without explicit permission. However, this requires
learning a new programming language and would require the consumer of the
script to perform compilation to ensure the security.

I'm not sure how many functions would be disabled, but I estimate it's a
much lower number than 90%. For instance, if a function is pure (i.e., has
no side effects), that function would be considered safe. That said, I'll
start sifting this list of functions and see what list I come up with:

http://php.net/quickref.php


> While the idea is certainly not bad, I'm not sure you could write
> sensible plugins for applications with only a few string functions at
> hand. My gut instinct tells me you'll run into something like "I wish I
> had this dir() to get the files in this directory" more sooner than
> later. Last plugin (for Drupal) I wrote for example hooked into the File
> API and saves/retrieves uploads to/from MogileFS. So that's file access
> AND network access, and those would quite probably the first on the list
> to be blacklisted. And if you only blacklist a few, disable_functions
> might be enough.
>

Valid points. Your Drupal plugin example could use several of the functions
initially blacklisted. However, the developer would then be able to, upon
reading the documentation and requirements for your plugin OR seeing the
error raised when attempting to sandbox your script, make an informed
decision as to how much they trust you, the provider of the script, and,
whether the perceived risk is worth the value. If the value is enough, the
developer would then be able to add the needed functions to the whitelist
and run your plugin.

Of note, the sandbox I'm suggesting would only impact internal functions
within files included with the sandboxing function. If Drupal, for example,
offered a file API and made it available to your plugin through the scoping
rules inherent in the application, you would be able to call those
functions without issue. The sandboxing would only limit direct calls to
unsafe, internal functions. The idea is to limit the access to the
environment that the framework or CMS can't properly limit. They can
already limit access to their environment through the API, and this
proposal would trust them to do that.

The disable_functions directive is indeed very handy, but it forces you to
give up the functions throughout the entire environment, whereas the
sandboxing would be limited to the scope of specific includes.
Additionally, shared host environments don't allow you to adjust this
setting.

To sum it up, to solve this problem I'd be more thinking about creating
> a specific DSL (like puppet) to fill my needs and not try to make people
> write some sort of 50%-PHP with constant lookup which functions are
> allowed and which are not.
>

The hope would be that you wouldn't have to constantly look up the
functions that are allowed. Rather, you'd use the functions you need and
the consumer of your plugin would decide if your plugin merited trusting
you with the "unsafe" internal functions you used. While the consumer might
not be able to audit every plugin they use, the sandboxing would bring to
light the plugins that needed extra attention and caution.

Excellent feedback, Florain. Thanks!

Adam

Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL

[Ilia Alshanetsky]

Option #1 seems like a good way to go to me.

On Fri, Mar 2, 2012 at 7:34 AM, Pierre Joye  wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
>
> I'm in favor of option #1, as it gives enough time to our users to
> migrate by reducing the maintenance period to only one year.
>
> Suggestions or comments welcome,
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3.11 planning

[jpauli]

2012/3/6 Derick Rethans 

> On Tue, 6 Mar 2012, Johannes Schlüter wrote:
>
> > just a quick note on 5.3.11 planning:
> >
> > We will migrate to git in roughly one week. I'll give it a few days to
> > verify migration works fine afterwards and then start the 5.3.11
> > process. Best is to get outstanding fixes in early. ;-)
>
> I'd like to get my simple ZEND_DONT_UNLOAD_MODULES patch in:
>
> Index: Zend/zend_API.c
> ===
> --- Zend/zend_API.c (revision 322920)
> +++ Zend/zend_API.c (working copy)
> @@ -2134,7 +2134,7 @@
>
>  #if HAVE_LIBDL
>  #if !(defined(NETWARE) && defined(APACHE_1_BUILD))
> -   if (module->handle) {
> +   if (module->handle && !getenv("ZEND_DONT_UNLOAD_MODULES")) {
>DL_UNLOAD(module->handle);
>}
>  #endif
>
> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


+1 for this one :)

Julien

Re: [PHP-DEV] '

[Reindl Harald]

Am 06.03.2012 01:13, schrieb Kris Craig:
> On Windows (where I generally do most of my scripting grunt work), 
> I typically use Notepad++ and it highlights
>  
> On Mon, Mar 5, 2012 at 4:11 PM, Reindl Harald  > wrote:
> Am 06.03.2012 01:03, schrieb Kris Craig:
> > I've never understood the "it's easier to read" argument since I've 
> found
> > it to be exactly the opposite.  The  > me, makes it more difficult to "at a glance" see where the PHP code 
> begins
> 
> if you hvae a usebale editor  would become different colors
> only in notepad or on the shell you would not see php-code but
> who does develop this way these days?

FIRST:
do NOT top post after get a reply below your text
or how do you imagine that anybody can follow a
thread where answers randomly before and after
the quotet text?

SECOND:
it is simply clear that it highlights ""

the "" is much easier readable as ""




signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Quoting (Was: Re: [PHP-DEV] '

[Derick Rethans]

On Mon, 5 Mar 2012, Kris Craig wrote:

> On Windows (where I generally do most of my scripting grunt work), I
> typically use Notepad++ and it highlights 

Please read
"http://ch2.php.net/reST/php-src/trunk_README.MAILINGLIST_RULES"; which
states:

"3. Do not top post. Place your answer underneath anyone you wish to
quote and remove any previous comment that is not relevant to your
post."

For more information on how to quote properly on mailinglists:

http://www.netmeister.org/news/learn2quote.html

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3.11 planning

[Derick Rethans]

On Tue, 6 Mar 2012, Johannes Schlüter wrote:

> just a quick note on 5.3.11 planning:
> 
> We will migrate to git in roughly one week. I'll give it a few days to
> verify migration works fine afterwards and then start the 5.3.11
> process. Best is to get outstanding fixes in early. ;-)

I'd like to get my simple ZEND_DONT_UNLOAD_MODULES patch in:

Index: Zend/zend_API.c
===
--- Zend/zend_API.c (revision 322920)
+++ Zend/zend_API.c (working copy)
@@ -2134,7 +2134,7 @@
 
 #if HAVE_LIBDL
 #if !(defined(NETWARE) && defined(APACHE_1_BUILD))
-   if (module->handle) {
+   if (module->handle && !getenv("ZEND_DONT_UNLOAD_MODULES")) {
DL_UNLOAD(module->handle);
}
 #endif

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3.11 planning

[Pierre Joye]

as well as the magic quotes regression issue. I assigned it to you
yesterday, patch there.

2012/3/6 Pierre Joye :
> hi,
>
> See security@, there are two that must be in.
>
> 2012/3/6 Johannes Schlüter :
>> Hi,
>>
>> just a quick note on 5.3.11 planning:
>>
>> We will migrate to git in roughly one week. I'll give it a few days to
>> verify migration works fine afterwards and then start the 5.3.11
>> process. Best is to get outstanding fixes in early. ;-)
>>
>> Please ping me if there are outstanding fixes you desperately want to
>> get in.
>>
>> johannes
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3.11 planning

[Pierre Joye]

hi,

See security@, there are two that must be in.

2012/3/6 Johannes Schlüter :
> Hi,
>
> just a quick note on 5.3.11 planning:
>
> We will migrate to git in roughly one week. I'll give it a few days to
> verify migration works fine afterwards and then start the 5.3.11
> process. Best is to get outstanding fixes in early. ;-)
>
> Please ping me if there are outstanding fixes you desperately want to
> get in.
>
> johannes
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: HEADS UP: 5.4 branch is open again

[David Soria Parra]

On 2012-03-05, Matthew Weier O'Phinney  wrote:
> On 2012-03-02, David Soria Parra  wrote:
>> just a heads up. The PHP_5_4 branch is open for commits again.
>
> Related: With 5.4.0 out... how soon will the cutover to git occur?

March 15.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] 5.3.11 planning

[Johannes Schlüter]

Hi,

just a quick note on 5.3.11 planning:

We will migrate to git in roughly one week. I'll give it a few days to
verify migration works fine afterwards and then start the 5.3.11
process. Best is to get outstanding fixes in early. ;-)

Please ping me if there are outstanding fixes you desperately want to
get in.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Pierre Joye]

hi,

May I suggest to discuss that on php-general?

On Tue, Mar 6, 2012 at 10:47 AM, Lester Caine  wrote:
> Markus Fischer wrote:
>>
>> On 06.03.2012 00:08, Lester Caine wrote:
>>>
>>> The ISP hosting these sites has not got back to me yet, but it would
>>> seem that when they updated from 5.3.9 to 5.3.10 they also switched off
>>> short_open_tag when previously it had been on.
>>
>>
>> I've learned it also the hard way the ISPs or Hosters did change INI
>> settings.
>> I've started to document their INIs for every new version and compare them
>> immediately once they upgraded to spot the differences. Worked well for me
>> (as
>> long as I had to be dependent on such companies), YMMV.
>
>
> I'd only taken over managing these sites in the last month which is why I
> was panicking a bit. I've only just finished cloning all the site data to
> one of my own systems and cloning the config would have been the next step
> :) Not having had time to review the code I did not even know where the
> problems were ...
>
> Kris - this is just about ' templates, it is much better to see  than  and
> this seems to be used by a number of frameworks - hence fixing the problem
> in 5.4 ...
>
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Lester Caine]

Markus Fischer wrote:

On 06.03.2012 00:08, Lester Caine wrote:

The ISP hosting these sites has not got back to me yet, but it would
seem that when they updated from 5.3.9 to 5.3.10 they also switched off
short_open_tag when previously it had been on.


I've learned it also the hard way the ISPs or Hosters did change INI settings.
I've started to document their INIs for every new version and compare them
immediately once they upgraded to spot the differences. Worked well for me (as
long as I had to be dependent on such companies), YMMV.


I'd only taken over managing these sites in the last month which is why I was 
panicking a bit. I've only just finished cloning all the site data to one of my 
own systems and cloning the config would have been the next step :) Not having 
had time to review the code I did not even know where the problems were ...


Kris - this is just about 'templates, it is much better to see  than  and this 
seems to be used by a number of frameworks - hence fixing the problem in 5.4 ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Stas Malyshev]

Hi!


Thoughts?


This is a fine idea, however actually doing it is not that easy. Note 
that knowing which function is "safe" is pretty hard, but that's only a 
start. Plugin code, for example, can call functions outside plugin 
context, while passing all kinds of arguments - is it safe or not? It 
depends on the context - e.g. plugin may need access to the database - 
directly or through some API - but that opens the door to various SQL 
injections and other mischief, etc. etc.
So while the idea is fine, designing a working sandbox is a very 
complicated task. That said, if you have any ideas - you're welcome to 
propose.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Markus Fischer]

On 06.03.2012 00:08, Lester Caine wrote:

The ISP hosting these sites has not got back to me yet, but it would
seem that when they updated from 5.3.9 to 5.3.10 they also switched off
short_open_tag when previously it had been on.


I've learned it also the hard way the ISPs or Hosters did change INI 
settings. I've started to document their INIs for every new version and 
compare them immediately once they upgraded to spot the differences. 
Worked well for me (as long as I had to be dependent on such companies), 
YMMV.


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs

[Florian Anderiasch]

Hi,
On 03/06/2012 08:34 AM, Adam Jon Richardson wrote:
[...]
> 1) Internal functions seen as universally safe would by default be allowed
> (e.g, str_replace(), array_pop(), etc.)
> 2) Unsafe internal functions would have to be explicitly declared (e.g.,
> file(), stream_*, etc.)
> 3) Any includes or requires within the sandboxed code would be forced to
> meet the same restrictions. (tricky)
> 4) Code containing unsafe functions not included in the whitelist would
> raise an error.
[...]
> Thoughts?

Isn't that basically what all template engines tried to solve before
with giving you a defined subset of tokens that are more or less
directly converted to php code? The benefit I see is that plugin
developers wouldn't need to learn a new DSL (domain-specific language),
but use PHP code. Just that it's not PHP if you disable 90% of the
functions available.

While the idea is certainly not bad, I'm not sure you could write
sensible plugins for applications with only a few string functions at
hand. My gut instinct tells me you'll run into something like "I wish I
had this dir() to get the files in this directory" more sooner than
later. Last plugin (for Drupal) I wrote for example hooked into the File
API and saves/retrieves uploads to/from MogileFS. So that's file access
AND network access, and those would quite probably the first on the list
to be blacklisted. And if you only blacklist a few, disable_functions
might be enough.

To sum it up, to solve this problem I'd be more thinking about creating
a specific DSL (like puppet) to fill my needs and not try to make people
write some sort of 50%-PHP with constant lookup which functions are
allowed and which are not.

Greetings,
Florian

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Ralf Lang]

Am 06.03.2012 01:13, schrieb Kris Craig:

On Windows (where I generally do most of my scripting grunt work), I
typically use Notepad++ and it highlights

Sometimes you get an alert and have to debug foreign code in situ. Then 
this echo where there is none written. I could live with removing it at a 
sane point in time.


Given, I only see house rules, it's forbidden for anything new.


--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL

[Pierre Joye]

hi,

On Mon, Mar 5, 2012 at 11:56 PM, Matthew Weier O'Phinney
 wrote:

> I did, actually. I still agree with Sebastian's proposal. While the PHP
> group may want to push for faster adoption, the pattern I've observed
> over and over is that ISPs and distributions -- particularly those with
> LTS offerings --

There is no nothing of LTS, and I do not think there will ever be, in
PHP. But yes, that's the role of the distributions to do it.

>  tend to adopt a minor version only when the new minor
> version supplanting it has been released. Does it make sense? No. Is it
> what happens? Yes.

This behavior, and from a distribution point of view, has been based
on their experiences with our relatively poor releases process or
quality (from a BC point of view and other related things).

The fact that debian was already planing 5.4 for debian-next before
5.4 was even final shows that this is what they expect. I got the same
feedback from ISPs or other distributions. Indeed one or the other may
prefer longer time frames, or some details changed, but all in all
they like what we do now.

It is also important to move forward and consider what we have now to
take decisions and not what we have been doing or what has been done.
Things change, if we don't see it we can't expect our users to see it
either.

>  As such, I think it makes a lot of sense to base the
> lifetime of 5.3 based on when 5.4 is released.

5.4 was released on March, 1st. That's why I asked this question now
while it should have been done before.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php