# [off] PHP: a fractal of bad design - Thread: https://externals.io/message/59652 - Original archive: https://news-web.php.net/php.internals/59652 - Started by Adir Kuhn on 2012-04-10T16:20:41+00:00 - Messages: 40 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/59652.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #59652 — Adir Kuhn — 2012-04-10T16:20:41+00:00 URL: https://externals.io/message/59652#59652 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 --- ## #59655 — Gustavo Lopes — 2012-04-10T16:31:56+00:00 URL: https://externals.io/message/59652#59655 · In reply to: #59652 > 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/ > 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 --- ## #59654 — Pierre Joye — 2012-04-10T16:31:57+00:00 URL: https://externals.io/message/59652#59654 · In reply to: #59652 hi, > 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/ 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 --- ## #59656 — Stas Malyshev — 2012-04-10T16:38:08+00:00 URL: https://externals.io/message/59652#59656 · In reply to: #59652 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 --- ## #59662 — Kris Craig — 2012-04-10T17:59:50+00:00 URL: https://externals.io/message/59652#59662 · In reply to: #59656 On Tue, Apr 10, 2012 at 9:38 AM, Stas Malyshev wrote: > Hi! > > > […] > link for > > […] > > 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. > +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 --- ## #59664 — Tom Boutell — 2012-04-10T18:18:01+00:00 URL: https://externals.io/message/59652#59664 · In reply to: #59654 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, > > > > > […] > > 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 --- ## #59666 — Stas Malyshev — 2012-04-10T18:27:22+00:00 URL: https://externals.io/message/59652#59666 · In reply to: #59664 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 --- ## #59667 — Kris Craig — 2012-04-10T18:28:01+00:00 URL: https://externals.io/message/59652#59667 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > […] > > It always amuses me PHP people think perl is stupid and vice versa. > Both languages have their use case, sometimes I even use them side by > side in the same project. PHP daemons and forking is not exactly what > I would depend on working reliably. > Umm at what point did I say PERL is "stupid?" PERL is like the duct-tape of scripting languages; it can be used for just about anything, though there's almost always a more specialized solution. It serves a purpose. But that being said, PERL has tons of flaws and other issues all its own. That's why it amuses me whenever I see a PERL person get on a soapbox about PHP. Hypocrisy is funny. > > > […] > > Exactly. There's a lot to improve and sometimes it can be done with > little to now bc breaks. (And some breaks I would not mind if done > right and for the right reasons). > > > - -- > Ralf Lang > Linux Consultant / Developer > Tel.: +49-170-6381563 > Mail: lang@b1-systems.de > > B1 Systems GmbH > Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+EeBcACgkQCs1dsHJ/X7DtXgCgjnp/QXvpkSo/i5AYamIVhp+s > xS4AoO3vO25gDlvTyziUC0k3GYo19KDE > =Yt9n > -----END PGP SIGNATURE --- ## #59669 — Lester Caine — 2012-04-10T18:49:57+00:00 URL: https://externals.io/message/59652#59669 · In reply to: #59667 Kris Craig wrote: > PERL is like the duct-tape > of scripting languages; it can be used for just about anything, though > there's almost always a more specialized solution. It serves a purpose. Perhaps not the most ideal of comparisons ... The last thing you use 'duct-tape' for is sealing ducts ... you need to use the right tape for THAT job :) My own problem is convincing customers that the systems they have been using reliably for 10 years NEED to change. PHP does a good job for all of my customers and they see no reason to have to change things. What they have been doing for years has not changed in years so why change. Once on is used to the warts, 'fixing them' is an even more annoyance, so please can we stop complaining about things that are broken ... and leave those of us who are more than happy with what we have to just carry on 'doing things all wrong' :) -- 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 --- ## #59672 — Pierre Joye — 2012-04-10T19:50:50+00:00 URL: https://externals.io/message/59652#59672 · In reply to: #59664 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 --- ## #59679 — Ronald Chmara — 2012-04-10T22:39:20+00:00 URL: https://externals.io/message/59652#59679 · In reply to: #59652 > 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 --- ## #59721 — Yasuo Ohgaki — 2012-04-11T07:29:53+00:00 URL: https://externals.io/message/59652#59721 · In reply to: #59652 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 --- ## #59727 — Crocodile — 2012-04-11T08:14:15+00:00 URL: https://externals.io/message/59652#59727 · In reply to: #59721 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 > 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 --- ## #59728 — Lester Caine — 2012-04-11T08:29:28+00:00 URL: https://externals.io/message/59652#59728 · In reply to: #59721 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 --- ## #59734 — Luke Scott — 2012-04-11T15:19:21+00:00 URL: https://externals.io/message/59652#59734 · In reply to: #59652 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 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 --- ## #59736 — Ralph Schindler — 2012-04-11T15:46:57+00:00 URL: https://externals.io/message/59652#59736 · In reply to: #59728 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 --- ## #59737 — Lester Caine — 2012-04-11T16:06:30+00:00 URL: https://externals.io/message/59652#59737 · In reply to: #59736 Ralph Schindler wrote: > Hey Lester, > > > […] > > 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 --- ## #59738 — Anthony Ferrara — 2012-04-11T17:28:52+00:00 URL: https://externals.io/message/59652#59738 · In reply to: #59737 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: > > […] > > > 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 --- ## #59747 — Lester Caine — 2012-04-11T18:44:52+00:00 URL: https://externals.io/message/59652#59747 · In reply to: #59738 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 --- ## #59754 — johannes@schlueters.de — 2012-04-11T21:05:18+00:00 URL: https://externals.io/message/59652#59754 · In reply to: #59747 > Anthony Ferrara wrote: > > […] > > 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 --- ## #60170 — Hartmut Holzgraefe — 2012-04-18T08:34:40+00:00 URL: https://externals.io/message/59652#60170 · In reply to: #59652 > 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 --- ## #60171 — Hartmut Holzgraefe — 2012-04-18T08:44:17+00:00 URL: https://externals.io/message/59652#60171 · In reply to: #59734 > 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 --- ## #60172 — Philip Olson — 2012-04-18T08:53:01+00:00 URL: https://externals.io/message/59652#60172 · In reply to: #60170 > > > […] > > 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 … 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 --- ## #60469 — Richard Lynch — 2012-05-05T16:17:34+00:00 URL: https://externals.io/message/59652#60469 · In reply to: #59666 > Hi! > > > […] > > 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 --- ## #60499 — Tjerk Anne Meesters — 2012-05-07T03:32:30+00:00 URL: https://externals.io/message/59652#60499 · In reply to: #60469 > > […] > > 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. --- Next page: https://externals.io/message/59652.md?page=2