Is PHP vulnerable to Buffer oveflow?

From this book: Securing PHP Web Applications

To add buffer overflow prevention to the guestbook application, we’ll need to perform
two tasks:
• Verify that we’re running the latest stable version of the operating system, PHP,
and database.
• Add length checks to all data coming into the application.
On average, this should take a couple of hours of time—not a bad investment to
prevent one of the most vicious types of attacks.

C

ONSEQUENCES OF A BUFFER OVERFLOW
If all this sounds ominous, it should. But just in case you’re not thoroughly convinced
that buffer overflow attacks are an unmitigated bad thing, take a look at some of the
more common consequences of buffer overflows:
• Injection attacks, which enable hackers to insert code, SQL statements, or just
about anything else into your application
• Arbitrary code attacks, in which hackers can gain direct, root-level access to the
server’s operating system, allowing them to completely take over the server
• Denial-of-service attacks, which cause the server to get so bogged down in executing
malicious code (usually an infinite loop or other meaningless instructions)
that it doesn’t have the resources to perform normal tasks
• Remote exploits, where your server is used as a staging point to attack other servers

The htmlentities() and htmlspecialchars() functions assume an 8-character
entity. Most of the time this isn’t a problem. As we noted above, the vast majority of
computing is done in English, although this is changing as the Internet becomes
more widely available outside of North America and Western Europe. What happens
when a user (or a hacker, depending purely upon motivations) inserts a Greek UTF-8-
encoded character into your Web form, which you then pass to htmlentities() for
sanitization before displaying it in the browser? When the HTML entity encoder in
PHP encounters this Greek HTML entity that is larger than the current 8-character
buffer, PHP will simply increase the size of the buffer by 2 characters. Unfortunately, if
the HTML entity is 11 characters long, the buffer will overflow and allow for arbitrary
code to be executed

What is your idea?

Buffer overflows do not exist in interpreted languages, but they may exist in the language parser itself (i.e. PHP). PHP is written in C, your PHP applications are written in PHP. Thus, your PHP applications are safe from buffer overflows, but PHP is not.

Then a PHP application is vulnerable to buffer overflow, But checking all the data for their length taking time! Is there any better way?Which variable must check and has priority?

Buffer overflows do not exist in interpreted languages

why?

http://www.hardened-php.net/suhosin/