Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guys
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Adir Kuhn
ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035
PSMI - Professional Scrum Master I
Hi folks,
today I read this post, I think that some points are valid, follow the
link for you guyshttp://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
This is really long. I stopped reading in full when he complained about
the error-code model.
Is there anything actually susceptible of being actioned upon there or
it's just the usual "PHP is inconsistent" rant -- something we can all
agree on some degree, but which is usually irrelevant given BC concerns?
--
Gustavo Lopes
hi,
Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guyshttp://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Sorry but this list is not a SEO booster. Thanks for your understanding,
PS: This blog brings zero thing new, got many wrong facts and only
repeats what have been said for over a decade about parameters order.
Not sure how one can have so much free time in his hand to write such
useless things.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying "this was fixed in PHP
5.x.y." If it was fixed, why is it on your laundry list still?
hi,
Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guyshttp://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Sorry but this list is not a SEO booster. Thanks for your understanding,
PS: This blog brings zero thing new, got many wrong facts and only
repeats what have been said for over a decade about parameters order.
Not sure how one can have so much free time in his hand to write such
useless things.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Hi!
Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying "this was fixed in PHP
5.x.y." If it was fixed, why is it on your laundry list still?
What exactly valid points? == is a converting operator, === is a strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's "useless". Well, a lot of things would be
useless if you don't want to know how to use them.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying "this was fixed in PHP
5.x.y." If it was fixed, why is it on your laundry list still?What exactly valid points? == is a converting operator, === is a
strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's "useless". Well, a lot of things would
be
useless if you don't want to know how to use them.
He has a few valid points in the part I read before I got bored...
$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
//you're in.
}
Yes, one should have validated the input...
But you don't have to be THAT naive to think that the hashed value of
an SQL injection attack just isn't going to work, so it's "safe"...
I'll bet I have some of these in my (recent) code, for that matter.
On the other hand, if you accept type juggling, you have to expect the
other cases he has for == being a bit strange.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
What exactly valid points? == is a converting operator, === is a
strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's "useless". Well, a lot of things would
be
useless if you don't want to know how to use them.He has a few valid points in the part I read before I got bored...
$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
//you're in.
}Yes, one should have validated the input...
But you don't have to be THAT naive to think that the hashed value of
an SQL injection attack just isn't going to work, so it's "safe"...I'll bet I have some of these in my (recent) code, for that matter.
On the other hand, if you accept type juggling, you have to expect the
other cases he has for == being a bit strange.
Validated or not, why would type juggling even come into the picture
if both variables are of the same type?
123 == "123abc" // sure, why not
"61529519452809720693702583126814" ==
"61529519452809720000000000000000" // WAT?!
In the above, only the first ~50% of an md5 hash has to be correct.
This gets even worse for SHA256 hashes.
Hello internals,
I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling rules
well, but I'm shocked by this to say the least...
In my opinion this should change no matter the BC breaks it will create,
this one affects security big time. It's good I actually hash my passwords
in the MySQL and not on the PHP side, but I have seen hash comparations
with == all the time. And now that this has been discussed in detail I
expect this to be used as an attack method grow wide.
07.05.2012 5:32 пользователь "Tjerk Anne Meesters" datibbaw@php.net
написал:
What exactly valid points? == is a converting operator, === is a
strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's "useless". Well, a lot of things would
be
useless if you don't want to know how to use them.He has a few valid points in the part I read before I got bored...
$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
//you're in.
}Yes, one should have validated the input...
But you don't have to be THAT naive to think that the hashed value of
an SQL injection attack just isn't going to work, so it's "safe"...I'll bet I have some of these in my (recent) code, for that matter.
On the other hand, if you accept type juggling, you have to expect the
other cases he has for == being a bit strange.Validated or not, why would type juggling even come into the picture
if both variables are of the same type?123 == "123abc" // sure, why not
"61529519452809720693702583126814" ==
"61529519452809720000000000000000" // WAT?!In the above, only the first ~50% of an md5 hash has to be correct.
This gets even worse for SHA256 hashes.
On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Hello internals,
I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling rules
well, but I'm shocked by this to say the least...
In my opinion this should change no matter the BC breaks it will create,
this one affects security big time. It's good I actually hash my passwords
in the MySQL and not on the PHP side, but I have seen hash comparations
with == all the time. And now that this has been discussed in detail I
expect this to be used as an attack method grow wide.
07.05.2012 5:32 пользователь "Tjerk Anne Meesters" datibbaw@php.net
написал:
Forgive me if I'm missing something, but why are people using == for
security-sensitive string comparisons (like hashed passwords) in the first
place?! If you needs something that's safe, isn't that what strcmp() and
strcasecmp() are for? For my part, I pretty much never use == on string
comparison, though admittedly that's probably just a matter of having
having come from a C background before PHP.
That being said, I agree that this definitely should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over 10
years and I was never aware of this bizarre behavior, either). I don't
know the history of this, but I at least would consider it to be a bug. A
rather large one, in fact; though I think some of the fears expressed are a
bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO. But if that really is a lingering
concern, I'd suggest targetting the fix for PHP 6, since people would (or
at least should) expect that some PHP 5 code may behave differently in PHP
6 anyway given that it's a major release
--Kris
On Mon, 07 May 2012 10:31:00 +0200, Kris Craig kris.craig@gmail.com
wrote:
That being said, I agree that this definitely should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over
10 years and I was never aware of this bizarre behavior, either). I
don't
know the history of this, but I at least would consider it to be a bug.
A rather large one, in fact; though I think some of the fears expressed
are a bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO.
This has already been discussed in its own thread, see
http://comments.gmane.org/gmane.comp.php.devel/72790 ; see also
https://bugs.php.net/bug.php?id=54547
Doing away entirely with this behavior (e.g. making " 2" == "2" compare
false) would be a rather large BC break, that discussion is restricted to
whether integers in strings should be treated differently from integer
literals for comparison purposes when their range is exceeded. I wrote a
patch for that, and, while not really caring one way or the other, I'm not
convinced it's necessary and I some have consistency concerns (though
float overflows already get a similar treatment).
--
Gustavo Lopes
On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:
On Mon, 07 May 2012 10:31:00 +0200, Kris Craig kris.craig@gmail.com
wrote:That being said, I agree that this definitely should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over
10 years and I was never aware of this bizarre behavior, either). I don't
know the history of this, but I at least would consider it to be a bug.
A rather large one, in fact; though I think some of the fears expressed
are a bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO.This has already been discussed in its own thread, see
http://comments.gmane.org/**gmane.comp.php.devel/72790http://comments.gmane.org/gmane.comp.php.devel/72790; see also
https://bugs.php.net/bug.php?**id=54547https://bugs.php.net/bug.php?id=54547Doing away entirely with this behavior (e.g. making " 2" == "2" compare
false) would be a rather large BC break, that discussion is restricted to
whether integers in strings should be treated differently from integer
literals for comparison purposes when their range is exceeded. I wrote a
patch for that, and, while not really caring one way or the other, I'm not
convinced it's necessary and I some have consistency concerns (though float
overflows already get a similar treatment).--
Gustavo Lopes
Agreed. While it's no secret that I believe optional strong typing would
be helpful in this context, setting that aside I would definitely not want
to see implicit conversions like "2" == 2 or even " 2" == 2 go away (though
I do wish more PHP devs were familiar with the various trim() functions
lol).
That being said, this is what had me scratching my head from a previous
message in this thread:
$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
//you're in.
}
The thought that $a == $b would actually evaluate to TRUE is utterly
absurd.... Only catch is, it doesn't. As I was sharpening my pitchfork
getting ready to argue why this should be considered a bug and not
conflated with implicit conversions like " 2" == 2, I decided to do a
little test script against 5.3.11. I was unable to reproduce the behavior
being reported in the above example. In my tests, $a == $b returned FALSE.
As it should.
@Richard Could you clarify what you were trying to illustrate with that
code? I wasn't able to find anything wrong with how PHP handled it. So
either you were mistaken or I misunderstood your point (if the latter,
please tell me how so I can try again to repro the problem you're raising
concern about).
So with that in mind, the point I raised in the second paragraph of my last
email is moot because I was referring to behavior that doesn't actually
exist (again, unless I was testing for the wrong thing somehow?). Implicit
conversions like " 1" == 1.0 I fully support so long as they can both be
converted to numbers without loss of precision.
--Kris
On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt
wrote:
On Mon, 07 May 2012 10:31:00 +0200, Kris Craig kris.craig@gmail.com
wrote:That being said, I agree that this definitely should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over
10 years and I was never aware of this bizarre behavior, either). I
don't
know the history of this, but I at least would consider it to be a bug.
A rather large one, in fact; though I think some of the fears expressed
are a bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO.This has already been discussed in its own thread, see
http://comments.gmane.org/**gmane.comp.php.devel/72790<;
http://comments.gmane.org/gmane.comp.php.devel/72790>;; see also
https://bugs.php.net/bug.php?**id=54547<;
https://bugs.php.net/bug.php?id=54547>;Doing away entirely with this behavior (e.g. making " 2" == "2" compare
false) would be a rather large BC break, that discussion is restricted to
whether integers in strings should be treated differently from integer
literals for comparison purposes when their range is exceeded. I wrote a
patch for that, and, while not really caring one way or the other, I'm
not
convinced it's necessary and I some have consistency concerns (though
float
overflows already get a similar treatment).--
Gustavo LopesAgreed. While it's no secret that I believe optional strong typing would
be helpful in this context, setting that aside I would definitely not want
to see implicit conversions like "2" == 2 or even " 2" == 2 go away (though
I do wish more PHP devs were familiar with the varioustrim()functions
lol).That being said, this is what had me scratching my head from a previous
message in this thread:$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
//you're in.
}The thought that $a == $b would actually evaluate to
TRUEis utterly
absurd.... Only catch is, it doesn't. As I was sharpening my pitchfork
getting ready to argue why this should be considered a bug and not
conflated with implicit conversions like " 2" == 2, I decided to do a
little test script against 5.3.11. I was unable to reproduce the behavior
being reported in the above example. In my tests, $a == $b returned FALSE.
As it should.
juggling won't happen here, because both sides are strings, and they aren't
numerical strings, so that example was bogus indeed.
the discussion here is about whether it is not expected that the numerical
strings will compared as numbers even in they can only represented as
number if some kind of precision loss occurs.
about numerical strings:
http://php.net/manual/en/language.operators.comparison.php
"If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a
numberhttp://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
and
the comparison performed numerically. These rules also apply to the
switchhttp://www.php.net/manual/en/control-structures.switch.php
statement.
The type conversion does not take place when the comparison is === or !==
as this involves comparing the type as well as the value."
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks <arvids.godjuks@gmail.com
wrote:
Hello internals,
I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling
rules
well, but I'm shocked by this to say the least...
In my opinion this should change no matter the BC breaks it will create,
this one affects security big time. It's good I actually hash my
passwords
in the MySQL and not on the PHP side, but I have seen hash comparations
with == all the time. And now that this has been discussed in detail I
expect this to be used as an attack method grow wide.
07.05.2012 5:32 пользователь "Tjerk Anne Meesters" datibbaw@php.net
написал:Forgive me if I'm missing something, but why are people using == for
security-sensitive string comparisons (like hashed passwords) in the first
place?! If you needs something that's safe, isn't that whatstrcmp()and
strcasecmp()are for? For my part, I pretty much never use == on string
comparison, though admittedly that's probably just a matter of having
having come from a C background before PHP.That being said, I agree that this definitely should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over 10
years and I was never aware of this bizarre behavior, either). I don't
know the history of this, but I at least would consider it to be a bug. A
rather large one, in fact; though I think some of the fears expressed are a
bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO. But if that really is a lingering
concern, I'd suggest targetting the fix for PHP 6, since people would (or
at least should) expect that some PHP 5 code may behave differently in PHP
6 anyway given that it's a major release
I agree with Rasmus (and others) on this one (
internals@lists.php.net/msg57949.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg57949.html), type
numeric conversion on strings on both sides should only happen if both
strings can be represented as numbers without losing data/precision.
if one or both of the two sides can't be converted to numeric without data
loss, then we should compare them as strings.
the patch from Cataphract (attached at https://bugs.php.net/bug.php?id=54547)
implements this behavior
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I agree with Rasmus (and others) on this one
(internals@lists.php.net/msg57949.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg57949.html), type
numeric conversion on strings on both sides should only happen if both
strings can be represented as numbers without losing data/precision.
if one or both of the two sides can't be converted to numeric without data
loss, then we should compare them as strings.
the patch from Cataphract (attached at
https://bugs.php.net/bug.php?id=54547) implements this behavior
+1 ... that patch has been lying on a dusty shelf for more than a year =p
Easy - you see == everywhere and === is used rarely, in docs you see it in
some places like strpos(). This is one thing that has to be communicated
through every channel available (including docs) with clear examples that
show why it should be used instead of ==.
Take me for example, I never had any idea that comparing two hashes that
start with numbers can generate a logical truth despite the hashes being
different. I haven't seen anything related to this in docs and never
stumbled upon in the internet, ever. So I use == for comparing strings all
the time. Now I will change that because I have the knowledge why I should
use === instead of ==.
Well, now I do know, from this mailing list (witch is for PHP development)
- not many user-land developers read this list.
And in my previous message I said essentially the same as you did, just in
different words and style. English is not my native language and I have
been learning the British variant of it, so it's more formal that
American English :)
2012/5/7 Kris Craig kris.craig@gmail.com
On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Hello internals,
I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling
rules
well, but I'm shocked by this to say the least...
In my opinion this should change no matter the BC breaks it will create,
this one affects security big time. It's good I actually hash my passwrds
in the MySQL and not on the PHP side, but I have seen hash comparations
with == all the time. And now that this has been discussed in detail I
expect this to be used as an attack method grow wide.
07.05.2012 5:32 пользователь "Tjerk Anne Meesters" datibbaw@php.net
написал:Forgive me if I'm missing something, but why are people using == for
security-sensitive string comparisons (like hashed passwords) in the first
place?! If you needs something that's safe, isn't that whatstrcmp()and
strcasecmp()are for? For my part, I pretty much never use == on string
comparison, though admittedly that's probably just a matter of having
having come from a C background before PHP.That being said, I agree that this definitely should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over 10
years and I was never aware of this bizarre behavior, either). I don't
know the history of this, but I at least would consider it to be a bug. A
rather large one, in fact; though I think some of the fears expressed are a
bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO. But if that really is a lingering
concern, I'd suggest targetting the fix for PHP 6, since people would (or
at least should) expect that some PHP 5 code may behave differently in PHP
6 anyway given that it's a major release--Kris
Hello internals,
I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling rules
well, but I'm shocked by this to say the least..
you have to see this in the "web context" where all input from a
HTTP client arrives as strings without type information (and some
database result data comes in as string data, too)
In that context it perfectly makes sense that
"1" == "1.0"
returns true even if both operands are strings.
"123ABF453..." == "123DFEABC..." is a different story though,
and guess what? These are not considered equal, at least not
by the 5.3.6 instance on the system i'm currently testing with:
<?php
$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
echo "you're in";
} else {
echo "no, you don't get in that easy!";
}
?>
will print "no, you don't get in that easy!" just fine
--
hartmut
Validated or not, why would type juggling even come into the picture
if both variables are of the same type?
For the simple reason that web forms return all input as strings, even
if the input is actually meant to be numeric
Many PHP database backend functions also return all result fields
as strings regardless of the actual result type, e.g. mysql_fetch_(),
mysqli_fetch_() and pg_fetch_*() (although that's more debatable)
So if both operands look numeric (even though they are actually of
type string) type juggling kicks, and in your MD5 example it
unfortunately kicks in with a conversion to float for both sides
and you're running into the "never compare floats for equality"
trap ... (which is being worked on for the string comparison case
though, i just don't have the bug number at hand right now)
--
hartmut
Validated or not, why would type juggling even come into the picture
if both variables are of the same type?For the simple reason that web forms return all input as strings, even
if the input is actually meant to be numericMany PHP database backend functions also return all result fields
as strings regardless of the actual result type, e.g. mysql_fetch_(),
mysqli_fetch_() and pg_fetch_*() (although that's more debatable)
Granted, I realized that my comment came across a bit too generic.
What I meant to say is that the type juggling should be applied within
its realm of usefulness and skipped otherwise lest it tell me "they're
both pretty big numbers" :)
I've always felt overly pedantic when I used === or strcmp() in string
comparisons (assuming the equality edge cases were not an issue; e.g.
same string composition).
So if both operands look numeric (even though they are actually of
type string) type juggling kicks, and in your MD5 example it
unfortunately kicks in with a conversion to float for both sides
and you're running into the "never compare floats for equality"
trap ... (which is being worked on for the string comparison case
though, i just don't have the bug number at hand right now)
I'm assuming that you're referring to this bug reference:
https://bugs.php.net/bug.php?id=54547
The proposed patch therein looks okay, though I'm not sure why the
added test case is for 64bit systems only; seems to me that it can /
should be run for other systems too.
I was very surprised when I came across the == issue sometime ago. IMO
strings should be compared as strings. They should never be converted to
integer.
1=="1" // always convert the number value to a string and then
compare it
"foo" == 0 // should return false
"123abc" == "123nth" // compare as string. Do not convert to numeric values
"0"==0 // true
0=="0." // false
PHP is great but if we can work together to remove the flaws, then we can
make it even greater. We have to leave the past behind us and look at where
we want PHP to be in the next 5 years
Best regards,
While it's not the prettiest of side effects in php, I don't agree it should be "fixed"
On top of a massive BC break, it's not as if the results are inconsistent. Learning php means learning how type juggling works.
At most, I'd remove the part that truncates numeric strings like "123abc" and always convert them to 0, because that's almost never an intended effect. One could argue that "123" == 123 is, however.
I was very surprised when I came across the == issue sometime ago. IMO
strings should be compared as strings. They should never be converted to
integer.1=="1" // always convert the number value to a string and then
compare it
"foo" == 0 // should return false"123abc" == "123nth" // compare as string. Do not convert to numeric values
"0"==0 // true
0=="0." // falsePHP is great but if we can work together to remove the flaws, then we can
make it even greater. We have to leave the past behind us and look at where
we want PHP to be in the next 5 yearsBest regards,
At most, I'd remove the part that truncates numeric strings like
"123abc" and always convert them to 0, because that's almost never
an intended effect.
I too find it hard to think of the situation in which data must be
stored, even in a temporary form, as "123abc" but is meant to be
equivalent to 123. But it obviously has happened a bunch after all
these years.
Maybe a non-accidental example is where "123a", 123b", and "123c" are
all expected to be juggled to 123 -- i.e. the code is purposely
utilizing the PHP behavior in place of explicit truncation in order to
group certain items together. I'm 99.999% sure I've never done this,
but it would be devilishly hard to find the bugs that would come from
changing this behavior. Enough that I could see it being a major event
that tarnishes the release of PHP-dot-whatever-makes-this-change.
I also want to point out, as I did the other month when this came up,
that MySQL does autoconversion that is identical to this case [1], and
with **MP pairings so absurdly common, it makes sense to keep this
behavior in PHP for this reason alone.
-- S.
[1] SELECT '123abc' = 123 // true in MySQL (but not in all RDBMSes)
One could argue that "123" == 123 is, however.
I was very surprised when I came across the == issue sometime ago. IMO
strings should be compared as strings. They should never be converted to
integer.1=="1" // always convert the number value to a string and then
compare it
"foo" == 0 // should return false"123abc" == "123nth" // compare as string. Do not convert to numeric values
"0"==0 // true
0=="0." // falsePHP is great but if we can work together to remove the flaws, then we can
make it even greater. We have to leave the past behind us and look at where
we want PHP to be in the next 5 yearsBest regards,
Nothing's stopping you from using === for integer comparison or
validating your integer string using either ctype_digit() or
is_numeric() before comparing it. (The difference between these two
functions is is_numeric() allows for decimal points)
I was very surprised when I came across the == issue sometime ago. IMO
strings should be compared as strings. They should never be converted to
integer.1=="1" // always convert the number value to a string and then
compare it
"foo" == 0 // should return false"123abc" == "123nth" // compare as string. Do not convert to numeric values
"0"==0 // true
0=="0." // falsePHP is great but if we can work together to remove the flaws, then we can
make it even greater. We have to leave the past behind us and look at where
we want PHP to be in the next 5 yearsBest regards,
hi Tom,
Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying "this was fixed in PHP
5.x.y." If it was fixed, why is it on your laundry list still?
Nothing in his post is valid.
The == vs === is a PHP 101 problem, if one does not know the
difference, then there is no hope yet to even try to figure other
possible good points.
Everything else are the same stuff everyone has once complained about
and did not want to change because of BC reasons.
Nothing new, nothing to see, simple SEO oriented rant.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
today I read this post, I think that some points are valid, follow the link for
you guys
Could you name a few and explain why you think they are valid and what
you propose to do to fix them? This article is huge and if you want to
start a discussion that makes sense (as opposed to a rant which is, I am
sure, very therapeutic for the author of the post but I'm not sure why
should we care) I think the approach of "read the whole thing and guess
what I meant by 'some points'" is not the best one.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Tue, Apr 10, 2012 at 9:38 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
today I read this post, I think that some points are valid, follow the
link for
you guysCould you name a few and explain why you think they are valid and what
you propose to do to fix them? This article is huge and if you want to
start a discussion that makes sense (as opposed to a rant which is, I am
sure, very therapeutic for the author of the post but I'm not sure why
should we care) I think the approach of "read the whole thing and guess
what I meant by 'some points'" is not the best one.
+1
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
Do you know why a full 1/3 of the internet uses PHP? BECAUSE IT WORKS!!
It is easy for newcomers and veterans alike. It's very forgiving when it
comes to typing and other semantics. As far as an error stack goes, PHP
really doesn't need once IMHO because the error messages are already
surprisingly precise (with a few notable exceptions lol), typically telling
you not just what the error is but exactly where it is, right down to the
line number! Personally, I think that's just fucking awesome.
I started programming at the age of 12 using GW BASIC on my old 286 (I
remember how excited I was when my brother managed to obtain a pirated copy
of QuickBASIC lol). I later "matured" into C/C++. I didn't start using
PHP until I was 19 or 20. It's been my favorite language to work in ever
since. It always amuses me when PERL developers go on their little
soapboxes about how "real" programmers all think PHP is stupid lol.
Granted, PHP has MANY flaws, some of which are accurately mentioned in the
article (though as Pierre pointed out, it doesn't actually raise any new
points; and yes I did read the whole thing, including the comments). There
are some things that PERL and "Ruby with [sic?!] Rails" do better. But
that's why we're here. Instead of trying to use the Internals list to
boost the SEO of your blog, why not actually contribute to make the
language better? Or do you prefer to just be an armchair quarterback?
--Kris
Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guys
"Ideally, don’t tell me anything!"
That's doable. No point trying to talk to a ranter.
-Ronabop
Hi,
It was fun to read. I understand he just don't like PHP.
His article may be good for novice users to understand how PHP will behave.
I guess he learned PHP a lot, but he lists framework feature as
missing. I wander why. He seems to like Python, but Python's multibyte
support was awful until recent.
Anyway,
http://www.php.net/manual/en/security.database.sql-injection.php
I've never read this page. This page must be improved...
I haven't read all, but there may be other places that may help.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Stopped reading after encountered "E_ACTUALLY_ALL", "for ($foo as &$bar)" -
these things required me to google or to refer to docs to ensure I was not
missing something. And, yes, I should have stopped after the words "don’t
tell me anything!". People who refuse to listen do not deserve to be heard.
2012/4/11 Yasuo Ohgaki yohgaki@ohgaki.net
Hi,
It was fun to read. I understand he just don't like PHP.
His article may be good for novice users to understand how PHP will behave.I guess he learned PHP a lot, but he lists framework feature as
missing. I wander why. He seems to like Python, but Python's multibyte
support was awful until recent.Anyway,
http://www.php.net/manual/en/security.database.sql-injection.php
I've never read this page. This page must be improved...I haven't read all, but there may be other places that may help.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
Anyway,
http://www.php.net/manual/en/security.database.sql-injection.php
I've never read this page. This page must be improved...
That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not need
'prepared statements', just parameters ). One of the first things I implement on
any code that I'm porting. Does away with any agro over escaping strings and is
totally save 'injection' wise.
--
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
Hey Lester,
That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not
need 'prepared statements', just parameters ). One of the first things I
implement on any code that I'm porting. Does away with any agro over
escaping strings and is totally save 'injection' wise.
While I generally agree, 'just parameters' does have it's limitations.
Sometimes there are special character sequences that can be exploited to
escape out of a quoted value in a SQL string.
Offhand, this comes to mind about MySQL:
http://bugs.mysql.com/bug.php?id=8378
-ralph
Ralph Schindler wrote:
Hey Lester,
That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not
need 'prepared statements', just parameters ). One of the first things I
implement on any code that I'm porting. Does away with any agro over
escaping strings and is totally save 'injection' wise.While I generally agree, 'just parameters' does have it's limitations. Sometimes
there are special character sequences that can be exploited to escape out of a
quoted value in a SQL string.Offhand, this comes to mind about MySQL:
http://bugs.mysql.com/bug.php?id=8378
Well if you must use a simple database ;)
I've never used MySQL simply because it has yet to get to the same standard as
Firebird ... But I'm talking about passing parameters direct to '?' entries in
the SQL - something which if it CAN be broken then the database is also broken?
The database handles the 'data' going into a single field at a time.
--
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
Lester,
Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):
$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
$stmt->bindParam(1, $var);
$stmt->execute();
Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
first, that will successfully inject into the query thanks to how PDO
emulates prepares.
A problem that true prepared statements (MySQLi and if PDO has emulate
prepares off) is immune to...
Anthony
Ralph Schindler wrote:
Hey Lester,
That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not
need 'prepared statements', just parameters ). One of the first things I
implement on any code that I'm porting. Does away with any agro over
escaping strings and is totally save 'injection' wise.While I generally agree, 'just parameters' does have it's limitations.
Sometimes
there are special character sequences that can be exploited to escape out
of a
quoted value in a SQL string.Offhand, this comes to mind about MySQL:
http://bugs.mysql.com/bug.php?id=8378Well if you must use a simple database ;)
I've never used MySQL simply because it has yet to get to the same standard
as Firebird ... But I'm talking about passing parameters direct to '?'
entries in the SQL - something which if it CAN be broken then the database
is also broken? The database handles the 'data' going into a single field at
a time.--
Lester Caine - G8HFLContact - 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
Anthony Ferrara wrote:
Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
$stmt->bindParam(1, $var);
$stmt->execute();Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
first, that will successfully inject into the query thanks to how PDO
emulates prepares.A problem that true prepared statements (MySQLi and if PDO has emulate
prepares off) is immune to...
Try doing that with a real database ;)
Firebird is not susceptible to this sort of problem. And I have still to find
any use for PDO in real systems. It's just another layer that gets in the way of
processing data securely. Emulating things half cocked is simply another
security hole 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
Anthony Ferrara wrote:
Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
$stmt->bindParam(1, $var);
$stmt->execute();Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
first, that will successfully inject into the query thanks to how PDO
emulates prepares.A problem that true prepared statements (MySQLi and if PDO has emulate
prepares off) is immune to...Try doing that with a real database ;)
If PDO decided to use emulation by default (which has benefits like
fewer roundtrips etc.) it's not necessarily the issue from the database.
And that this doesn't work is obvious with emulation - PDO doesn't parse
the SQL and has no understanding of "SET NAMES", neither does the MySQL
client lib used. The proper way to set the encoding is by using the
DSN's charset option.
johannes
I do agree with a lot of what was being said. But what can you do?
These are mostly quirks of the language. You learn to live with them.
I don't make excuses for it. It is what it is.
The only thing that infuriates me is the ternary operator being left
associative. I want that fixed - screw bc on that one! I have been
programming for 10 years and that one still confuses me! Most people
just add parentheses to "fix" the problem. I wish someone would write
an RFC to change this to right associative like every other language!
hint hint
Luke Scott
Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guyshttp://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Adir Kuhn
ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035
PSMI - Professional Scrum Master I
The only thing that infuriates me is the ternary operator being left
associative. I want that fixed - screw bc on that one! I have been
programming for 10 years and that one still confuses me! Most people
just add parentheses to "fix" the problem. I wish someone would write
an RFC to change this to right associative like every other language!
hint hint
i actually never noticed this until now as i keep it as a best practice
to never nest ternaries anyway, in any language. To me it's at least as
much a sign for a desseased mind as using multiple exclamation marks
!!!11eleven ;)
The problem i see though is that in code that really relies on this it
may become a real nightmare to track down what goes wrong if evaluation
order is changed if you're not aware of that change having happened.
An E_DEPRECATED may help here, but will also produce a lot of false
positives for those using parentheses? Or can we add enough parser
magic to only throw warnings for the unsafe uses? ...
--
hartmut
Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guys
as stuff like this comes up again and again (although not in as epic
lenght as this one) i've been thinking whether it might make sense to
have some
"PHP Gotchas, how they came to be, and why we can't simply fix them"
FAQ section in the manual or wiki?
If nothing else it would at least help with dealing with this kind
of rant (nothing new here, move along, your concerns were already
covered in ### in great detail), but also might help that would
indeed want to understand why some things are as they are.
I'd rather proactively own this kind of discussions than just
jump into them whenever they arise elsewhere ...
--
hartmut
Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guysas stuff like this comes up again and again (although not in as epic
lenght as this one) i've been thinking whether it might make sense to
have some"PHP Gotchas, how they came to be, and why we can't simply fix them"
FAQ section in the manual or wiki?
If nothing else it would at least help with dealing with this kind
of rant (nothing new here, move along, your concerns were already
covered in ### in great detail), but also might help that would
indeed want to understand why some things are as they are.I'd rather proactively own this kind of discussions than just
jump into them whenever they arise elsewhere …
Hello Hartmut,
Agreed, and I think it belongs in the manual. An example (not being
proposed as such, but is a rough idea):
Why are function naming schemes seemingly random?
PHP glues many different API's together, and sometimes this
gets messy. PHP leans towards the C variant which is why the
likes of `strlen()` vs `str_replace()` exists, and …
As opposed to our current approach, which is via mailing lists and
typically "RTFM." or "BC. Read archives." or the like. Ack!
And also include possible solutions/recommendations like this PHP FAQ
entry about haystack,needle ordering, which includes the following
text:
A simple rule of thumb is as follows: Array function parameters
are ordered as "needle, haystack" whereas String functions are the
opposite, so "haystack, needle".
And thankfully there are already a lot of sites to steal the questions
from, and often answers live within their user comments. :)
Regards,
Philip