

htmlspecialchars does not throw E_WARNING on multibyte problems - rustc
https://bugs.php.net/bug.php?id=47494

======
birken
If you find an odd situation in PHP due to backwards compatibility or
whatever, I highly recommend you just make a wrapper function to do what you
want.

Another example of a common mistake with default functionality:

Did you know

json_decode('null')

and

json_decode('{')

both return the same thing, NULL. One is correct, one isn't. The only way to
actually tell the difference? Also call json_last_error() to make sure there
wasn't an error parsing the json. Pretty inconvenient to do every time (and
most people wont). Solution: Wrap it.

At Thumbtack we have lots of wrapper functions which take care of situations
where a built-in function doesn't have an interface we like. Most of them are
purely for convenience though, not situations like this where the default
output does something potentially misleading.

~~~
masklinn
> Solution: Wrap it.

Conversely, cut your losses and use something saner with better internal and
API coherence.

~~~
maratd
Please take your hipster elitism somewhere else. Every language has warts and
learning how to avoid them is always a good idea.

~~~
kstrauser
That's not elitism; that's reality. Notice that PHP is pretty much the sole
language garnering this reaction? No one actively makes fun of C#, Python,
Clojure, Haskell, Perl, Java, etc., even when they dislike them.

For example, I don't care for Java at all, but I admit that it's a really good
implementation of a language I just don't happen to like very much. Same for
C#. My reasons for not using it have nothing to do with the language itself
(which is perfectly decent by all accounts). Programmers joke about Perl
looking like line noise, but even that's a criticism of how some people use
the language and not anything bad about Perl directly.

But no one other than PHP programmers seems to have anything good to say about
PHP. It's nearly universally disrespected as an insecure, inconsistent, buggy
mess. That's very unusual - perhaps unique - among major programming
languages. Maybe there's a reason that non-Java programmers have a grudging
respect for Java, non-Python programmers can find things they like about
Python, but non-PHP programmers almost never have anything good to say about
PHP.

When a lot of subject matter experts vocally dislike something, maybe that
thing is misunderstood. When nearly all of them dislike it, perhaps there's a
reason for it.

~~~
wvenable
> But no one other than PHP programmers seems to have anything good to say
> about PHP.

The people least familiar with the language have the most negative to say
about it. Making fun of PHP is pretty much a fad -- this particular topic,
about htmlspecialchars(), I heard originally 5 years ago and it just cycles
around and around. Even the most famously quoted articles about PHP's
shortcomings are typically at least 50% flat-out wrong and 25% opinion.

That being said, PHP has a fair share of warts -- it's a language with a long
history and rapid change with little overall direction.

~~~
brendoncrawford
_> The people least familiar with the language have the most negative to say
about it_

My 12 years of experience with PHP would beg to differ. It is, by ANY
standard, a terrible language. In fact, it's primary defense of being
"convenient" is not even true. Most developers would probably get a Django
site up and running in the same amount of time it would take them to get a
Cake or CodeIgniter site up and running.

------
geofft
In fairness, display_errors is a terrible idea -- do you actually want errors
thrown by your program to be interspersed with the HTML output of your
program?

This sort of stuff should be going to the error log. And it is, so "throws
error" and "error reporting" in the title are both inaccurate here. It does
throw an error; it merely refuses to send that error to the HTML output of the
page when display_errors is on. If normal, sane error reporting to the error
log is on, the error does show up there.

~~~
nwh
It only really makes sense when PHP is used in a shell. If nothing else, its
strange that a lot of PHP implementations have them turned on by default.

~~~
Firehed
Not really. People that turn off display_errors and set up proper logging
typically know what they're doing; it's a pretty sensible default for "my
first website" level of projects. Remember, those folks are just uploading PHP
files to their shared host - they don't have a local development environment,
let alone a custom-configured production setup.

Is it unfortunate that a lot of production sites run with stupid settings
because they aren't run by full-time software engineers or sysadmins? Sure.
But the accessibility of making changes is great, and most people would
consider it a good thing that people are taking an interest in learning how to
do this stuff themselves rather than outsourcing all of their technology
problems. After all, isn't that how most of us got started?

------
ecaron
This "bug" has been resolved since 01-Mar-2012 when 5.4 was released, and
there's a very straight-forward explanation of it if people would just RTFM.

This is the worst part of the PHP community - all the in-fighting when the
core developers don't bend over backwards to accommodate short-sighted
programmers who _know_ their conflicting demand is the one that should be
heard.

------
smsm42
The problem is that people have conflicting demands. They want all errors -
even most unobvious ones in most deep functions, in all outputs - be
immediately shown to them with all details, without having to do even minimal
amount of work, and then they want the whole system also be secure. It can not
work this way. If you want errors on the output, it can not be secure. If you
want secure defaults, you can not have server spewing errors to the output.

So we have a choice here - do we prefer, convenience or security? Given that
inconvenience is much less dangerous than insecurity, the choice for PHP
developers was security. In ideal world, where nobody runs their production
servers with display_errors=on and everybody understand the consequences of
their actions, this hack would not be needed. We live however in a real world,
where thousands of production sites are run with dislpay_errors, so we need to
account for this reality. It means somebody has to check their error log from
time to time. If it's too hard to do - install custom error handler and
override the default behavior.

------
gedrap
I start finding those arguments about PHP close to ones Adroid vs iPhone. Yes,
PHP is inconsistent and etc. But on the other hand, it just gets the shit
done. And for historical reasons, it has a huge community. When you add those
two factors together and stop being a hipster... It's not that bad, is it?

~~~
mikeash
It's terrible. PHP doesn't "get the shit done", although PHP _programmers_
can. There are far better languages for getting things done. Huge community is
not terribly attractive, as plenty of other, better languages have
sufficiently large communities.

I'd survive if I had to program in PHP, but it would definitely be a last
resort. It could be worse (Malbolge?) but I don't understand why people feel a
need to defend it or say it's not bad.

