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

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 ob

Re: [PHP-DEV] Scalar Type Hinting

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:

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

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 > > af

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

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

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

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

[PHP-DEV] SVN Account Request: huzaifas

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

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 real

Re: [PHP-DEV] Scalar Type Hinting

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 >

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

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 servic

RE: [PHP-DEV] Scalar Type Hinting

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

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

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

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

> - 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/noti

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

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

Re: [PHP-DEV] Scalar Type Hinting

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

RE: [PHP-DEV] Scalar Type Hinting

> 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 clo

Re: [PHP-DEV] Scalar Type Hinting

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 l

Re: [PHP-DEV] Scalar Type Hinting

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 w

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

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 ea

Re: [PHP-DEV] '

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 th

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

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 o

Re: [PHP-DEV] Scalar Type Hinting

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 wha

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

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 contr

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

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. S

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

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

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

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

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

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 ed

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

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 ove

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

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

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

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

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

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

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

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

Re: [PHP-DEV] '

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

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

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) upda

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

>> 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

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

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 dif

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

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

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

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.

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

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

Re: [PHP-DEV] '

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 e

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

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] '

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

Re: [PHP-DEV] 5.3.11 planning

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://ww

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

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 n

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

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 wou

Re: [PHP-DEV] 5.3.11 planning

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

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

> > > 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 an

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

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 mar

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

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

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

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: ; Dev

Re: [PHP-DEV] 5.3.11 planning

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,

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

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 e

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

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 a

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

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

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

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

[PHP-DEV] consider reverting E_ALL with E_STRICT

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, t

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

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

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 redu

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

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 wri

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

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

>> 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 argum

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

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 cont

[PHP-DEV] SVN Account Request: olemarkus

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

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

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

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 giv

Re: [PHP-DEV] 5.3.11 planning

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 outsta

Re: [PHP-DEV] '

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: >

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

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

Re: [PHP-DEV] 5.3.11 planning

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

Re: [PHP-DEV] 5.3.11 planning

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

Re: [PHP-DEV] 5.3.11 planning

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 ou

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

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

[PHP-DEV] 5.3.11 planning

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

Re: [PHP-DEV] '

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

Re: [PHP-DEV] '

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

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

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? I

Re: [PHP-DEV] '

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 I

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

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

Re: [PHP-DEV] '

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

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

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 of