Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)
There is not really a need to discuss the removal again, that's why I
ask for a simple vote:
+1: remove them (as it is now in HEAD)
-1: Restore them and always return FALSE (not 0)
0: I don't care, do what you wish, I never use them anyway
Feel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)
Thanks,
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.
Personally....
+1
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.Personally.... XX
VOTE CHANGED
-1
After a quick off-list discussion with Hannes (gotta' love Gmail
chat), I realized that I forgot to consider backwards-compatibility.
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?
Daniel Brown wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.
Personally....XXVOTE CHANGED -1 After a quick off-list discussion with Hannes (gotta' love Gmailchat), I realized that I forgot to consider backwards-compatibility.
I think a lot of people miss the point of these particular functions.
This isn't about whether to keep magic quotes or not, it is whether to
keep the function that tells you whether magic quote mangling is
enabled. There is a lot of code out there that checks to see if this
feature is on, and deals with that case. Having this function that
simply tells the code to take the other path will allow it to work.
This is not about restoring the magic quotes feature at all.
-Rasmus
Hi Rasmus,
Daniel Brown wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.
Personally....XXVOTE CHANGED -1 After a quick off-list discussion with Hannes (gotta' love Gmailchat), I realized that I forgot to consider backwards-compatibility.
I think a lot of people miss the point of these particular functions.
This isn't about whether to keep magic quotes or not, it is whether to
keep the function that tells you whether magic quote mangling is
enabled. There is a lot of code out there that checks to see if this
feature is on, and deals with that case. Having this function that
simply tells the code to take the other path will allow it to work.
This is not about restoring the magic quotes feature at all.
Exactly, I thought it was clear.
As I can see it was, the votes (not that much ;) in favor of keeping
the functions argue about your example, keep the if
(get_magic_quotes_gpc...) working without changes (if (php6)...).
Cheers,
Daniel Brown wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.
Personally....XXVOTE CHANGED -1 After a quick off-list discussion with Hannes (gotta' love Gmailchat), I realized that I forgot to consider backwards-compatibility.
I think a lot of people miss the point of these particular functions.
This isn't about whether to keep magic quotes or not, it is whether to
keep the function that tells you whether magic quote mangling is
enabled. There is a lot of code out there that checks to see if this
feature is on, and deals with that case. Having this function that
simply tells the code to take the other path will allow it to work.
This is not about restoring the magic quotes feature at all.
Exactly.
The problem is that if the function is removed then we are breaking
scripts for those few that actually check for MQ and deal with them.
The scripts by uneducated users that do not check for MQ will continue
to work as if nothing happened. However, by removing these functions
we are breaking all the scripts by the educated users who are
following best practices.
Furthermore, none of the MQ functions are even marked as depreciated yet.
What exactly is the gain in removing them completely?
All I'm asking is to keep PHP_FUNCTION(get_magic_quotes_gpc) { RETURN_FALSE; }
-Hannes
+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anyway
-1 (restore them) :)
-Hannes
I agree +1
Regards
Marco
+1
+1
Markus Fischer wrote:
+1
I didn't realized it until I read Rasmus' mail. In this case, -1 to not break BC.
Pierre Joye wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)Thanks,
+1
--
Jeremy Privett
C.E.O. & C.S.A.
Omega Vortex Corporation
Web: http://www.omegavortex.net
E-Mail: jeremy@omegavortex.net
Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
-1: Restore them and always return
FALSE(not 0)
I freely admit to not remembering a 2-year-old discussion, but it
seems to me for BC reasons you'd want to do this...
I know they've been marked "deprecated" and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
I know they've been marked "deprecated" and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?
Then we will continue to be at the same old issue of they exist, people will
continue to use them and never move away from them.
Mike
I know they've been marked "deprecated" and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?Then we will continue to be at the same old issue of they exist, people will
continue to use them and never move away from them.
Without expanding too much, I'd say that we're not going to
advertise the availability of the function, so people would no longer
use that. However, removal of the function won't instantly break all
legacy scripts. As Hannes and I were discussing off-list, I feel it's
something that should be removed in a Generation 7 or 8 release, but
with the function availability still existing in PHP5, I believe it's
too soon.
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?
I know they've been marked "deprecated" and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?Then we will continue to be at the same old issue of they exist, people will
continue to use them and never move away from them.Without expanding too much, I'd say that we're not going toadvertise the availability of the function, so people would no longer
use that. However, removal of the function won't instantly break all
legacy scripts. As Hannes and I were discussing off-list, I feel it's
something that should be removed in a Generation 7 or 8 release, but
with the function availability still existing in PHP5, I believe it's
Again, we are talking about PHP6 here. It is a one time opportunity to
drop these functions and be happy for the next 8 years.
But this has been discussed to death. Please say +1/-1/0 =)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
But this has been discussed to death. Please say +1/-1/0 =)
Pierre: Sorry, I didn't want to add to the noise, but for the sake of
completeness I'll give you my 0.
- Steph
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
I know they've been marked "deprecated" and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?Then we will continue to be at the same old issue of they exist, people will
continue to use them and never move away from them.
Err, no? magic quotes itself is removed - this is just the functions
to check if it's enabled or not.
Derick
+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anyway
+1 - remove them
Users can easily add these themselves, (if (!
function_exists('get_magic_quotes')) function get_magic_quotes()
{return false;}} or an "compat" include) no need to keep them around.
johannes
+1 - remove them
--Marcelo
+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anyway+1 - remove them
Users can easily add these themselves, (if (!
function_exists('get_magic_quotes')) function get_magic_quotes()
{return false;}} or an "compat" include) no need to keep them around.johannes
--
--
Marcelo Araujo
Founder & Software Architect
Cell Phone: +55 34 9144 1472
JMCodex (http://www.jmcodex.com)
skype: marcelocrosara
2008/2/5, Pierre Joye pierre.php@gmail.com:
Hi,
It seems that there is voice
+1: remove them (as it is now in HEAD)
Remove them , they are of no use.
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)
I can only find archives[1] that decide they should exist in PHP 6,
and NEWS[2] indicates this decision to be true. Where else was this
decision decided?
Them existing should depend on if PHP 6 wants a chance to run plenty
of PHP 5 code out-of-the-box. Is this desire known yet?
And since they return 0 now, why would the return value be changed to
false for this BC function?
Regards,
Philip
[1] http://marc.info/?t=114170222600003&r=1&w=2
[2] http://php.net/php6news
There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anyway
I don't care that much, but I think it would matter if the functions
just are there and return false (so -1).
for set_magic_quotes_runtime(), if "true" is passed, it should still
throw a fatal error, if "false" is passed it should not (or actually 1
vs 0).
Derick
2008/2/6, Derick Rethans derick@php.net:
I don't care that much, but I think it would matter if the functions
just are there and return false (so -1).for set_magic_quotes_runtime(), if "true" is passed, it should still
throw a fatal error, if "false" is passed it should not (or actually 1
yes if set_magic_quotes_runtime(true), a big fatal error ( under no
circustance a warning or notice) , if "false" it should emit either an
E_NOTICE or E_STRICT telling the magic_quotes_runtime is deprecated
and that using set_magic_quotes_runtime has no effect.
Although I still think this functions should be removed.
2008/2/6, Derick Rethans derick@php.net:
I don't care that much, but I think it would matter if the functions
just are there and return false (so -1).for set_magic_quotes_runtime(), if "true" is passed, it should still
throw a fatal error, if "false" is passed it should not (or actually 1yes if set_magic_quotes_runtime(true), a big fatal error ( under no
circustance a warning or notice) , if "false" it should emit either an
E_NOTICEorE_STRICTtelling the magic_quotes_runtime is deprecated
and that using set_magic_quotes_runtime has no effect.
Once again, it is not deprecated. It is dead, removed, deleted, the
features behind this horrible mq have been removed.
Although I still think this functions should be removed.
ok, your vote has been counted as +1 :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
-1
Pierre Joye schreef:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)Thanks,
-1
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)Thanks,
+1 - remove the functions
To make a script compatible one has to add
function get_magic_quotes_gpc(){return 0;}
in one of his library files.
I think the current change is somewhat similar to PHP_INI_ALL in PHP ->
PHP_INI_PERDIR for magic_quotes_gpc made in 4.2.3. It also could lead to
breakage but it was done besides the fact that it wasnt a major release (I
guess bugfix for security reasons...).
Now is coming a major release and my opinion is that the deprecated features
must be removed even in the cost of BC breakage.
Probably a general policy on BC breakages in major releases has to be
discussed and then decide on per-case basis.
If there is already such a policy or guidelines please point me to it.
-1
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)Thanks,
There is not really a need to discuss the removal again, that's why I
ask for a simple vote:
+1
--
Geoffrey Sneddon
<http://gsnedders.com/
Pierre Joye wrote:
Hi,
+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anyway
-1
-1
Suggestion to enhance the suggestion: return false + emit E_STRICT
message (but I am also fine with pure return false if people don't like
this suggestion).
Andi
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, February 05, 2008 12:23 PM
To: PHP internals
Subject: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in
head, get a "final" decisionHi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)Thanks,
Hi Andi,
-1
Suggestion to enhance the suggestion: return false + emit
E_STRICT
message (but I am also fine with pure return false if people don't like
this suggestion).
Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.
Cheers,
I'm going to rock the boat again I guess...
Suggestion to enhance the suggestion: return false + emit
E_STRICT
message (but I am also fine with pure return false if people don't like
this suggestion).Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.
Whatever happened to E_DEPRECATED? From Ilia's 5.3 summary last September:
Split off deprecation from E_STRICT into E_DEPRECATED 22
.. that was 22/28 votes.
Did I miss something? Or is it just on the TODO still?
- Steph
Cheers,
Hi Andi,
-1
Suggestion to enhance the suggestion: return false + emit
E_STRICT
message (but I am also fine with pure return false if people don't
like
this suggestion).Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.
Yeah, note that we sort of agreed to split off an E_DEPRECATED from
E_STRICT in PHP 5.3.
regards,
Lukas
Hi Andi,
-1
Suggestion to enhance the suggestion: return false + emit
E_STRICT
message (but I am also fine with pure return false if people don't
like
this suggestion).Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.Yeah, note that we sort of agreed to split off an
E_DEPRECATEDfrom
E_STRICTin PHP 5.3.regards,
Lukas
But in PHP 5.x, a well-written program should still be checking for magic
quotes so that it can undo the damage they cause if necessary. Not all
programs can control their environment, so checking those functions is
basically required if you want to run on a server over which you don't have
absolute control. I wouldn't say that's deprecated or a strict-violation.
So I guess I'm -1: Restore them, always return false, and throw E_DEPRECATED.
--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
Hi Andi,
-1
Suggestion to enhance the suggestion: return false + emit
E_STRICT
message (but I am also fine with pure return false if people don't
like
this suggestion).Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.Yeah, note that we sort of agreed to split off an
E_DEPRECATEDfrom
E_STRICTin PHP 5.3.regards,
LukasBut in PHP 5.x, a well-written program should still be checking for magic
quotes so that it can undo the damage they cause if necessary. Not all
programs can control their environment, so checking those functions is
basically required if you want to run on a server over which you don't
have absolute control.
-if (get_magic_quotes_gpc()) {
+if (function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc()) {
Hi Andi,
-1
Suggestion to enhance the suggestion: return false + emit
E_STRICT
message (but I am also fine with pure return false if people don't
like
this suggestion).Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.Yeah, note that we sort of agreed to split off an
E_DEPRECATEDfrom
E_STRICTin PHP 5.3.regards,
LukasBut in PHP 5.x, a well-written program should still be checking for magic
quotes so that it can undo the damage they cause if necessary. Not all
programs can control their environment, so checking those functions is
basically required if you want to run on a server over which you don't have
absolute control. I wouldn't say that's deprecated or a strict-violation.So I guess I'm -1: Restore them, always return false, and throw E_DEPRECATED.
But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so should anything else even remotely related
to them be gone. You have to fix your code anyway for it to work in PHP
6 (or even 5) without magic_crap..
--Jani
--
Patches/Donations: http://pecl.php.net/~jani/
So I guess I'm -1: Restore them, always return false, and throw
E_DEPRECATED.But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so should anything else even remotely related
to them be gone. You have to fix your code anyway for it to work in PHP
6 (or even 5) without magic_crap..
Code works without magic crap. Function is used to detect when data must
be uncrapped.
--
Tomas
So I guess I'm -1: Restore them, always return false, and throw
E_DEPRECATED.But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so should anything else even remotely related
to them be gone. You have to fix your code anyway for it to work in PHP
6 (or even 5) without magic_crap..Code works without magic crap. Function is used to detect when data must
be uncrapped.
But why would you need to check if the magic itself does not exist
anymore? :)
--
Patches/Donations: http://pecl.php.net/~jani/
So I guess I'm -1: Restore them, always return false, and throw
E_DEPRECATED.But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so should anything else even remotely related
to them be gone. You have to fix your code anyway for it to work in PHP
6 (or even 5) without magic_crap..Code works without magic crap. Function is used to detect when data must
be uncrapped.
It does not need to be "uncrapped" in php6, the magic quotes are GONE,
they do not exist anymore.
The only point to keep them is to let developers be lazy by not adding
a php version check (or function_exists).
Anyway, enough people has voiced their wishes. I will count the votes
and post the summary on Monday (== you still have two days to vote, if
you care).
Cheers,
So I guess I'm -1: Restore them, always return false, and throw
E_DEPRECATED.But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so should anything else even remotely related
to them be gone. You have to fix your code anyway for it to work in PHP
6 (or even 5) without magic_crap..Code works without magic crap. Function is used to detect when data must
be uncrapped.It does not need to be "uncrapped" in php6, the magic quotes are GONE,
they do not exist anymore.The only point to keep them is to let developers be lazy by not adding
a php version check (or function_exists).Anyway, enough people has voiced their wishes. I will count the votes
and post the summary on Monday (== you still have two days to vote, if
you care).
I say throw them out. Magic quotes are easy to simulate 100%.
Cheers,
Hi!
I say throw them out. Magic quotes are easy to simulate 100%.
I could cry by reading this sentence ;)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
So I guess I'm -1: Restore them, always return false, and throw
E_DEPRECATED.But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so should anything else even remotely related
to them be gone. You have to fix your code anyway for it to work in PHP
6 (or even 5) without magic_crap..Code works without magic crap. Function is used to detect when data must
be uncrapped.It does not need to be "uncrapped" in php6, the magic quotes are GONE,
they do not exist anymore.The only point to keep them is to let developers be lazy by not adding
a php version check (or function_exists).Anyway, enough people has voiced their wishes. I will count the votes
and post the summary on Monday (== you still have two days to vote, if
you care).Cheers,
Aren't some things just worth the BC break?
Having never used them, I can quite happily say bomb the bastards!
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Richard Quadling wrote:
Aren't some things just worth the BC break?
Having never used them, I can quite happily say bomb the bastards!
Agreed. For Phorum will just change our code from:
if ( get_magic_quotes_gpc() ) {
to:
if ( function_exists(get_magic_quotes_gpc) && get_magic_quotes_gpc() ) {
So, I guess I am +1
--
Brian Moon
Senior Developer/Engineer
When you care enough to spend the very least.
http://dealnews.com/
Richard Quadling wrote:
Aren't some things just worth the BC break?
Having never used them, I can quite happily say bomb the bastards!
Agreed. For Phorum will just change our code from:
if (
get_magic_quotes_gpc()) {to:
if ( function_exists(get_magic_quotes_gpc) &&
get_magic_quotes_gpc()) {
Or use a compatibility function. I use this one:
if (version_compare(phpversion(), $version) === 6) {
function get_magic_quotes_gpc() {
return false;
}
}
That code can easily be thrown into an application, and will have full
compatibility.
So, I guess I am +1
--
Brian Moon
Senior Developer/EngineerWhen you care enough to spend the very least.
http://dealnews.com/
Sam Barrow wrote:
Or use a compatibility function. I use this one:
if (version_compare(phpversion(), $version) === 6) {
functionget_magic_quotes_gpc(){
return false;
}
}
Ehh, I don't understand: how does that code work at all? (unless
version_compare() changed behavior, it should only ever return +1, 0 or
-1)...
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
0 for me
-1 for all the people who'll bug the mailing lists askign where they've gone
suggest: E_NOTICE or E_STRICT telling the magic_quotes_runtime has gone
BUT in the next php 5.2.X release so peeps get used to it!
Pierre Joye wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)Thanks,
Pierre Joye wrote:
-1: Restore them and always return
FALSE(not 0)
-1
-1. Keep the query functions and return FALSE. No need to unnecessarily
break b/c for scripts that were just trying to do the right thing by coping
with both possibilities. It's just one more roadblock to PHP 6 adoption.
Guys,
what's the verdict on this one? Right now, many already have
if(function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc())
in their code.
Now with the latest 5.3, that throws an E_STRICT!
Seriously, is that necessary?
David
Am 05.02.2008 um 21:23 schrieb Pierre Joye:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)There is not really a need to discuss the removal again, that's why I
ask for a simple vote:+1: remove them (as it is now in HEAD)
-1: Restore them and always returnFALSE(not 0)
0: I don't care, do what you wish, I never use them anywayFeel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)Thanks,
Hi David,
Guys,
what's the verdict on this one? Right now, many already have
if(function_exists('get_magic_quotes_gpc') &&
get_magic_quotes_gpc())in their code.
Now with the latest 5.3, that throws an E_STRICT!
This discussion was about HEAD (php6). But if any, 5.3 should raise a
E_DEPRECATED.
Cheers,
Am 27.02.2008 um 17:03 schrieb Pierre Joye:
Hi David,
On Wed, Feb 27, 2008 at 4:52 PM, David Zülke dz@bitxtender.com
wrote:Guys,
what's the verdict on this one? Right now, many already have
if(function_exists('get_magic_quotes_gpc') &&
get_magic_quotes_gpc())in their code.
Now with the latest 5.3, that throws an E_STRICT!This discussion was about HEAD (php6). But if any, 5.3 should raise a
E_DEPRECATED.
I know, but IIRC, Andi or someone else suggested that there should be
a warning in 5.3, but that was not discussed further.
I mean, really, what's the point? I have my check for magic quotes
there, along with a function_exists call. Why do I need to see the
stupid message. Removing it in PHP6 is nonsensical enough in my
opinion, but I can live with that. Now everyone adjusted their code to
deal with the specific situation - magic quotes will be removed in
PHP6, and all of a sudden, there is an E_STRICT, telling us what we
already know.
David
Hello David,
telling us what we already know.
I am not quite sure, that all developers, for example the junior one, know
that.
Am 27.02.2008 um 17:25 schrieb Lokrain:
Hello David,
telling us what we already know.
I am not quite sure, that all developers, for example the junior
one, know
that.
You mean my code should break because some ignorant noob is unaware
that PHP6, which is still months or years away, will throw out magic
quotes? A feature whose usage has been disencouraged since PHP5? My
code, that specifically checks for the existance of the magic quotes
feature since it is built with PHP6 support in mind? Is that what
you're telling me?
David
You mean my code should break because some ignorant noob is unaware
that PHP6, which is still months or years away, will throw out magic
quotes?
How a E_DEPRECATED will break your code? Please, I doubt there is a
need to begin this discussion again.
A feature whose usage has been disencouraged since PHP5? My
code, that specifically checks for the existance of the magic quotes
feature since it is built with PHP6 support in mind? Is that what
you're telling me?
I did not check the votes yet but I think the function will be
restored as empty bottle for the getter versions and with a warning
for the setter version.
Cheers,
Hi David,
I know, but IIRC, Andi or someone else suggested that there should be
a warning in 5.3, but that was not discussed further.
Because adding a waring in 5.x is a no-no.
I mean, really, what's the point? I have my check for magic quotes
there, along with a function_exists call. Why do I need to see the
stupid message. Removing it in PHP6 is nonsensical enough in my
opinion, but I can live with that. Now everyone adjusted their code to
deal with the specific situation - magic quotes will be removed in
PHP6, and all of a sudden, there is an E_STRICT, telling us what we
already know.
Yes, E_STRICT is wrong, it should E_DEPRECATED.