6 ms·

It shows the culture in PHP. They would rather keep a function around that doesn't work properly just so existing code still works instead of making everyone te

It shows the culture in PHP. They would rather keep a function around that doesn't work properly just so existing code still works instead of making everyone test that the new function works.

ericbarrett 5y ago
As another commenter points out, this is actually a quirk of the underlying MySQL C library, which has (or had) both functions.
gregjor 5y ago
It shows a trade-off between arbitrarily breaking code in production or not. Lots of PHP sites are hosted on services that don’t give the programmer control over the PHP version. If the hosting provider upgrades and breaks a bunch of sites that’s a problem every bit as serious (to the site’s owner) as unescaped HTML opening up XSS attacks.
- SilverRed 5y ago
  This is not sustainable or a desirable thing to keep. By accepting this state of things, no security fix with breaking changes can ever be implemented.
  - gregjor 5y ago
    With all respect your comment is both arrogant and unrealistic. Exactly how do we not accept this state of things? No one claims it's desirable, it just is: bad code is out there, and it's not easy to fix. What would you tell a small business that relies on clunky 10-year-old code to run their business? To rewrite it in a more modern language at huge expense and risk (given that a majority of rewrite projects fail)? Can you guarantee the new thing won't be just as obsolete and vulnerable and buggy in ten years? These kinds of problems -- poorly-written and vulnerable code, amateur programmers, lack of professionalism, maintaining back-compatibility with an installed base -- are not specific to PHP. They afflict the entire software industry, and always have. Who could have seen into the future back in 2000 (when I first got exposed to PHP) that a new site would get probed by an army of bots within five minutes of going live? Or that it would be even harder today than back then to find and hire experienced programmers? PHP has had many security fixes implemented since the early releases, but how can anyone force users of an open-source language to upgrade for their own good? Or pay someone to ferret out and fix vulnerabilities they have never got hit by? Even brand new code has this problem. Look at all of the cryptocurrency code written in the last few years. We read about hacks and thefts and vulnerabilities every day, and that was written by supposedly smart people with access to modern languages and with knowledge of the contemporary security issues. And it still gets hacked. If we knew how to write perfect code that would still be perfect into the future I'm sure we would do that but until then we'll have to live with what we have. So far it has been sustainable, just less than optimal, if by optimal we mean what we can imagine rather than what we, as programmers, actually deliver.
    - eska 5y ago
      Yes, yes, the poor companies. But do you ever consider the poor customers/users that put private information in the companies' databases? Or that the price they pay assumes the companies do not let their software rot for 10 years? Then there's the typical logical fallacy of taking a trivial problem of escaping SQL and conflating it with something more complicated, and comparing to eternal perfection.. yawn.
      - SilverRed 5y ago
        >companies do not let their software rot for 10 years? I think that one of the big mistakes made in the last 20 years is that every company needs its own custom software and that software is like an asset that you buy once and not a constant cost source. The vast majority of businesses have no need for custom software and should be using 3rd party services. Then those 3rd parties have the income to dedicate to keeping the software secure. Its honestly terrible how many local businesses have their own complex software built on some ancient version of a frame work which is sitting on an ancient server box in their office. Its a ticking time bomb no one wants to think about. Prolonging the explosion is not the solution.
        gregjor 5y ago
        Agreed. I often tell customers to use an off-the-shelf solution and get on with their real business. Custom software development is expensive, risky, and incurs long-term maintenance costs. I outright refuse to take on custom e-commerce sites or accounting or CRM systems at this point. About half the time the customer will find someone else who will happily bid on writing custom code despite my suggestion. That’s one reason the legacy code problem just gets bigger every year, and a lot of it shouldn’t have been written in the first place.
      - gregjor 5y ago
        Look at the major data breaches over the past decade -- TransUnion, Experian, multiple US government sites, etc. and point to one that was caused by a PHP SQL injection attack. This kind of thing can happen to anything accessible on the public internet. Do you know how old the software your bank uses is? Pretty much every government agency and utility you rely on? What price do you pay for that? A lot of that code has been rotting longer than any PHP web site. There's no logical fallacy. I wrote multiple times that escaping SQL is essentially trivial in PHP, and has been not only easy but the recommended best practice. The problem is lots of inexperienced programmers don't know the problem to begin with. They would write vulnerable code in any language. I had to work on a Rails site a few years ago that was vulnerable to XSS and SQL injection, even though Rails by default protects against those things. Someone had gone around all of that because they didn't understand the problem in the first place. I don't know that any language can protect us from that.
paulddraper 5y ago
https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/stackoverflow_has_become_sentient/ https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/sta...
heurisko 5y ago
That's not completely true. Over its evolution, PHP has removed some functions completely to provide better and more secure functionality, such as mysql_* in PHP 7.
tored 5y ago
No, every PHP release deprecates functions or fixes functions that is either considered bad or not working as intended. Quick search & I found these (note that some of the rfc's include multiple deprecations), but there is more if you bother to actually look. Stop spreading misinformation. https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 https://wiki.php.net/rfc/remove_deprecated_functionality_in_... https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a... https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_opti...

It shows the culture in PHP. They would rather keep a function around that doesn't work properly just so existing code still works instead of making everyone test that the new function works.

ericbarrett 5y ago

As another commenter points out, this is actually a quirk of the underlying MySQL C library, which has (or had) both functions.

gregjor 5y ago

It shows a trade-off between arbitrarily breaking code in production or not. Lots of PHP sites are hosted on services that don’t give the programmer control over the PHP version. If the hosting provider upgrades and breaks a bunch of sites that’s a problem every bit as serious (to the site’s owner) as unescaped HTML opening up XSS attacks.

SilverRed 5y ago
This is not sustainable or a desirable thing to keep. By accepting this state of things, no security fix with breaking changes can ever be implemented.
- gregjor 5y ago
  With all respect your comment is both arrogant and unrealistic. Exactly how do we not accept this state of things? No one claims it's desirable, it just is: bad code is out there, and it's not easy to fix. What would you tell a small business that relies on clunky 10-year-old code to run their business? To rewrite it in a more modern language at huge expense and risk (given that a majority of rewrite projects fail)? Can you guarantee the new thing won't be just as obsolete and vulnerable and buggy in ten years? These kinds of problems -- poorly-written and vulnerable code, amateur programmers, lack of professionalism, maintaining back-compatibility with an installed base -- are not specific to PHP. They afflict the entire software industry, and always have. Who could have seen into the future back in 2000 (when I first got exposed to PHP) that a new site would get probed by an army of bots within five minutes of going live? Or that it would be even harder today than back then to find and hire experienced programmers? PHP has had many security fixes implemented since the early releases, but how can anyone force users of an open-source language to upgrade for their own good? Or pay someone to ferret out and fix vulnerabilities they have never got hit by? Even brand new code has this problem. Look at all of the cryptocurrency code written in the last few years. We read about hacks and thefts and vulnerabilities every day, and that was written by supposedly smart people with access to modern languages and with knowledge of the contemporary security issues. And it still gets hacked. If we knew how to write perfect code that would still be perfect into the future I'm sure we would do that but until then we'll have to live with what we have. So far it has been sustainable, just less than optimal, if by optimal we mean what we can imagine rather than what we, as programmers, actually deliver.
  - eska 5y ago
    Yes, yes, the poor companies. But do you ever consider the poor customers/users that put private information in the companies' databases? Or that the price they pay assumes the companies do not let their software rot for 10 years? Then there's the typical logical fallacy of taking a trivial problem of escaping SQL and conflating it with something more complicated, and comparing to eternal perfection.. yawn.
    - SilverRed 5y ago
      >companies do not let their software rot for 10 years? I think that one of the big mistakes made in the last 20 years is that every company needs its own custom software and that software is like an asset that you buy once and not a constant cost source. The vast majority of businesses have no need for custom software and should be using 3rd party services. Then those 3rd parties have the income to dedicate to keeping the software secure. Its honestly terrible how many local businesses have their own complex software built on some ancient version of a frame work which is sitting on an ancient server box in their office. Its a ticking time bomb no one wants to think about. Prolonging the explosion is not the solution.
      - gregjor 5y ago
        Agreed. I often tell customers to use an off-the-shelf solution and get on with their real business. Custom software development is expensive, risky, and incurs long-term maintenance costs. I outright refuse to take on custom e-commerce sites or accounting or CRM systems at this point. About half the time the customer will find someone else who will happily bid on writing custom code despite my suggestion. That’s one reason the legacy code problem just gets bigger every year, and a lot of it shouldn’t have been written in the first place.
    - gregjor 5y ago
      Look at the major data breaches over the past decade -- TransUnion, Experian, multiple US government sites, etc. and point to one that was caused by a PHP SQL injection attack. This kind of thing can happen to anything accessible on the public internet. Do you know how old the software your bank uses is? Pretty much every government agency and utility you rely on? What price do you pay for that? A lot of that code has been rotting longer than any PHP web site. There's no logical fallacy. I wrote multiple times that escaping SQL is essentially trivial in PHP, and has been not only easy but the recommended best practice. The problem is lots of inexperienced programmers don't know the problem to begin with. They would write vulnerable code in any language. I had to work on a Rails site a few years ago that was vulnerable to XSS and SQL injection, even though Rails by default protects against those things. Someone had gone around all of that because they didn't understand the problem in the first place. I don't know that any language can protect us from that.

paulddraper 5y ago

https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/stackoverflow_has_become_sentient/ https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/sta...

heurisko 5y ago

That's not completely true. Over its evolution, PHP has removed some functions completely to provide better and more secure functionality, such as mysql_* in PHP 7.

tored 5y ago

No, every PHP release deprecates functions or fixes functions that is either considered bad or not working as intended. Quick search & I found these (note that some of the rfc's include multiple deprecations), but there is more if you bother to actually look. Stop spreading misinformation. https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 https://wiki.php.net/rfc/remove_deprecated_functionality_in_... https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a... https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_opti...