Ilia,
I think Wez's suggestion is the most practical one. Let's make sure
we haven't introduced any fatal errors into 5.2 (and demote them to
E_STRICT for now), and handle the rest of the suggestions afterwards.
Zeev
At 02:33 24/10/2006, Ilia Alshanetsky wrote:
I've been reading people's r
At 21:08 23/10/2006, Marcus Boerger wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
- Add a new severity E_DEPRECATED
- severities are u
Ilia Alshanetsky wrote:
I've been reading people's replies to Marcus' RFC in regard to
E_DEPRECATED and it seems that some people have expressed the want to
delay 5.2 until mucking around with error handling is done one way or
another. My simple answer to this is no.
SIMPLE QUESTION - I've ju
On 10/23/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
. E_DEPRECATED: Some language featre that is likely to go away.
s/likely/confirmed/. We can't speculatively deprecate a feature and
then change our minds. (The {} vs [] thing with strings comes to
mind).
I don't think we need to set
I've been reading people's replies to Marcus' RFC in regard to
E_DEPRECATED and it seems that some people have expressed the want to
delay 5.2 until mucking around with error handling is done one way or
another. My simple answer to this is no.
The long answer is as follows.
PHP 5.2.0 is no
Marcus Boerger wrote:
> - Add a new severity E_DEPRECATED
+1
> - severities are used as follows:
> . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
> removal would be two minor versions or one major version later. That is
> something that gets deprecated in 5.
Peter Brodersen wrote:
On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
I had left out SERVER filtering in the initial version for much the same
reasoning, but it turns out that a good chunk of holes were due to the
fact that people used $_SERVER['
On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>I had left out SERVER filtering in the initial version for much the same
>reasoning, but it turns out that a good chunk of holes were due to the
>fact that people used $_SERVER['REQUEST_URI'] unfilter
I'm not a voter, but I'd like to lobby for a fancier
E_STRICT...
E_STRICT is sounding more and more like runtime "lint".
I very much miss lint. (I'm sure it's still around, but
I've been programming in only php for the last few years.)
A key feature of lint that made it usable was that you
could
Derick Rethans wrote:
>> . E_STRICT any rule that reflects common strict standards, like OOP theory
>> that is considered harmless if not followed. For example the combination
>> 'abstract static' makes no sense in said theory but doesn't put our zend
>> engine in an unstable state.
>
Marcus Boerger wrote:
> Hello internals,
>
> after recent discussions (over the last three months)I finally made up my
> mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
> proposal is to do the following:
>
> - Add a new severity E_DEPRECATED
>
> - severities are used a
On 23-Oct-06, at 4:16 PM, Richard Lynch wrote:
Some ISPs will be quicker to upgrade LAMP than to let users build SSH
tunnels.
If your ISP does not give you SSH, perhaps it is time to find
yourself another ISP.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To un
On Fri, October 20, 2006 9:26 am, Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 10:24 AM, Lukas Kahwe Smith wrote:
>
>> Ilia Alshanetsky wrote:
>>
its funny that ext/mysql is supposed to stay around for BC
reasons even in PHP6, yet it has known unsolvable security issues.
>>> Such as?
>>
>
On Fri, October 20, 2006 9:35 am, Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 10:29 AM, Edin Kadribasic wrote:
>> "Known OO conventions" -> how Java people do it
>> "Its supposed to work that way" -> it works like that in Java
>> ...
>
> Java is just a single OO language out of many, http://
> en.
On Mon, October 23, 2006 12:38 pm, Rasmus Lerdorf wrote:
> I had left out SERVER filtering in the initial version for much the
> same
> reasoning, but it turns out that a good chunk of holes were due to the
> fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to
> teach people which
Marcus Boerger wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
+1 to them all.
Alan
--
PHP Internals - PHP Runtime Development Mailing
On Mon, October 23, 2006 2:08 pm, Marcus Boerger wrote:
> Hello internals,
+1, ditto on only major version for E_DEPRECATED to disappear
I'd go either way on E_ALL changing -- but would think that the Right
Thing is to leave it alone in 5.2, but make it mean *ALL* (even
E_STRICT) in 6.0
--
Some
On 23-Oct-06, at 3:08 PM, Marcus Boerger wrote:
- Add a new severity E_DEPRECATED
- severities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away.
Eearlierst
removal would be two minor versions or one major version later.
That is
something that ge
On Mon, 2006-10-23 at 21:29 +0200, Pierre wrote:
> On Mon, 23 Oct 2006 21:08:57 +0200
> [EMAIL PROTECTED] (Marcus Boerger) wrote:
>
> > Hello internals,
> >
> > after recent discussions (over the last three months)I finally made
> > up my mind over E_STRICT, deprecation warnings and OOP
> > mes
On Mon, 23 Oct 2006, Marcus Boerger wrote:
> after recent discussions (over the last three months)I finally made up my
> mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
> proposal is to do the following:
>
> - Add a new severity E_DEPRECATED
+1
> - severities are used
On Mon, 23 Oct 2006 21:08:57 +0200
[EMAIL PROTECTED] (Marcus Boerger) wrote:
> Hello internals,
>
> after recent discussions (over the last three months)I finally made
> up my mind over E_STRICT, deprecation warnings and OOP
> messages/rules. My idea proposal is to do the following:
>
> - Add
Hi Marcus,
+1 to everything here if it counts, but please can you simplify the role of
E_DEPRECATED by making it 'next major version only'? I can see all kinds of
problems with leaving that open to debate.
- Steph
Hello internals,
after recent discussions (over the last three months)I fi
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
- Add a new severity E_DEPRECATED
- severities are used as follows:
. E_DEPRECATED: Some langua
Hello,
On 10/23/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Pierre,
shouldn't we use E_NOTICE here? obviously there is something wrongwith
those calls
That's where our opinions differ. There is nothing wrong with these
calls and it is a documented behavior. If you take a look at my
Hello Pierre,
shouldn't we use E_NOTICE here? obviously there is something wrongwith
those calls and other functions that check their input typically raise them
as E_NOTICE or E_WARNING. In this case I personally would prefer E_NOTICE
and think E_STRICT is wrong. If we had E_DEPRECATED we could
publishing dbobj 0.8 at PECL
more on dbobj:
http://beeblex.com/lists/index.php/php.pecl.dev/3457?s=l%3Aphp.pecl.dev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
gmmktime() without parameters is broken in PHP 4 anyway. If you don't
give it arguments than it should default to the current date
and hour (in GMT for gmmktime() and in localtime for
mktime()). In both places this should result in t
On Mon, 23 Oct 2006, Pierre wrote:
> Hello,
>
> On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> >
> > > > > Yes, I see no point in pushing this responsibility into the userland,
> > > > > especially since its a BC break appearently.
> > >
Ilia Alshanetsky wrote:
On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:
Hi,
I just wanted to remind you that PHP 5.2.0 will be released with broken
and inconsistent input filtering.
Right now _SERVER is only passed through the input filter for apache 1
SAPI. All other SAPIs do not pass _SERVER
Hello,
On 10/23/06, Pierre <[EMAIL PROTECTED]> wrote:
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
>
> On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:
>
> > Hi,
> >
> > I just wanted to remind you that PHP 5.2.0 will be released with
> > broken
> > and inconsistent input filter
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Unilateral break? lol...
Actually it is no break at all, take PHP4 code move it to PHP and you
won't even see the warning because E_STRICT is not even shown by
default.
Anyway, I made my point, my patch prooves that this change i
Ilia Alshanetsky wrote:
Actually it is no break at all, take PHP4 code move it to PHP and you
won't even see the warning because E_STRICT is not even shown by default.
haha
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Unilateral break? lol...
Actually it is no break at all, take PHP4 code move it to PHP and you
won't even see the warning because E_STRICT is not even shown by
default.
On 23-Oct-06, at 11:26 AM, Pierre wrote:
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
On 23-Oct-0
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
On 23-Oct-06, at 6:41 AM, Pierre wrote:
> If you read the other replies to your initial question (which was
> wrong :), you will realize another thing, this is easily fixable with
> minimum effort and impact:
>
> http://pecl.php.ne
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:
> Hi,
>
> I just wanted to remind you that PHP 5.2.0 will be released with
> broken
> and inconsistent input filtering.
>
> Right now _SERVER is only passed through the input filter fo
On 23-Oct-06, at 6:41 AM, Pierre wrote:
If you read the other replies to your initial question (which was
wrong :), you will realize another thing, this is easily fixable with
minimum effort and impact:
http://pecl.php.net/~pierre/remove_mktime_strict.txt
No visible speed difference
I see no
On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:
Hi,
I just wanted to remind you that PHP 5.2.0 will be released with
broken
and inconsistent input filtering.
Right now _SERVER is only passed through the input filter for apache 1
SAPI. All other SAPIs do not pass _SERVER variables through the
On 23/10/06, Pierre <[EMAIL PROTECTED]> wrote:
Hello,
On 10/23/06, Richard Quadling <[EMAIL PROTECTED]> wrote:
> On 23/10/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> >
> > > > > Yes, I see no point in pushing this responsibility into the user
Hello,
On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Mon, 23 Oct 2006, Pierre wrote:
> On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
>
> > Yeah, but there is no point in calling mktime() without arguments as you
> > can use time() doing the same. It's just a friendly hint t
On Mon, 23 Oct 2006, Pierre wrote:
> On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
>
> > Yeah, but there is no point in calling mktime() without arguments as you
> > can use time() doing the same. It's just a friendly hint that you're
> > wasting CPU cycles. It's an E_STRICT message for
Hello,
On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> > > Yes, I see no point in pushing this responsibility into the userland,
> > > especially since its a BC break appearently.
> >
> > There is no BC break:
>
> I meant, there would be a
On 23/10/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> > > Yes, I see no point in pushing this responsibility into the userland,
> > > especially since its a BC break appearently.
> >
> > There is no BC break:
>
> I meant, there would be a BC break
Hello,
On 10/23/06, Richard Quadling <[EMAIL PROTECTED]> wrote:
On 23/10/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
>
> > > > Yes, I see no point in pushing this responsibility into the userland,
> > > > especially since its a BC break appearent
Hello,
On 10/23/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
Yeah, but there is no point in calling mktime() without arguments as you
can use time() doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's an E_STRICT message for s sake.
There is no point to keep th
Hello Stefan,
On 10/23/06, Stefan Esser <[EMAIL PROTECTED]> wrote:
Hi,
I just wanted to remind you that PHP 5.2.0 will be released with broken
and inconsistent input filtering.
Right now _SERVER is only passed through the input filter for apache 1
SAPI. All other SAPIs do not pass _SERVER vari
PHP 5 Bug Database summary - http://bugs.php.net
Num Status Summary (602 total including feature requests)
===[*Compile Issues]==
39197 Open How do I get shared library 'libphp5.so'?
===
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (633 total including feature requests)
===[Apache related]===
38670 Open Whole 4.4.x branch has problem with open_basedir option nested
from Apache2
Hi,
I just wanted to remind you that PHP 5.2.0 will be released with broken
and inconsistent input filtering.
Right now _SERVER is only passed through the input filter for apache 1
SAPI. All other SAPIs do not pass _SERVER variables through the filter.
This will be a major headache for people usi
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> > > Yes, I see no point in pushing this responsibility into the userland,
> > > especially since its a BC break appearently.
> >
> > There is no BC break:
>
> I meant, there would be a BC break if this feature gets dropped, which is the
> point of
Derick Rethans wrote:
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
Pierre wrote:
On 10/23/06, Pierre <[EMAIL PROTECTED]> wrote:
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced t
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
> Pierre wrote:
> > On 10/23/06, Pierre <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> > > > Use of mktime(0) and alike is improper use of the function, more over
> > > > generally it can
Pierre wrote:
On 10/23/06, Pierre <[EMAIL PROTECTED]> wrote:
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Use of mktime(0) and alike is improper use of the function, more over
> generally it can be traced to an undesired code behavior.
Which is? mktime(0) is just like mkti
52 matches
Mail list logo
