PARAM_INT works just fine for me with mysqlnd. Use INT...

The MySQL PDO driver code does not cover PARAM_BOOL. Hence, the driver signals a failure to the calling PDO core for PDO_PARAM_EVT_EXEC_PRE. The core, however, ignores the failure and returns true for a failed bind*() call. 

You filed the bug against PDO_MySQL. From PDO_MySQL perspective it is a feature request. If it was filed against PDO, I'd call it a bug.

> PARAM_INT works just fine for me...

Right; that's why I showed that as a proposed workaround.

> You filed the bug against PDO_MySQL. 

I am but a lowly PHP user; I knowest not its internal details. :-)

I think I've filed two earlier documentation reports, and this is
my first report on the actual working code itself.

When presented with a choice, I just picked the package that seemed 
to make the most sense to me.  Clearly it got to the right party so 
as to understand the issues involved. :-)

> From PDO_MySQL perspective it is a feature request. 

I can understand your perspective.  But maybe there should be some
corresponding documentation, perhaps in 
http://www.php.net/manual/en/pdostatement.bindvalue.php and
http://www.php.net/manual/en/pdostatement.bindparam.php , along the
lines of "not all data types are supported by all drivers; see this
page for details".  I just took a second look, and couldn't find
anything that would suggest that this is a missing feature.

> The core, however, ignores the failure and returns true for a 
> failed bind*() call....

> If it was filed against PDO, I'd call it a bug.

So perhaps this report should be "split" into two components?
I don't want to file a duplicate post, but it sounds like there
are two separate teams that need to address this.  Thanks!

I recently ran into this same issue and was very surprised by the unexpected, broken behavior of PDO::PARAM_BOOL. I bumped into this issue after disabling PDO::ATTR_EMULATE_PREPARES and noticed many of unit tests were suddenly failing. So it is even more surprising that this works when emulating prepares, but fails when using real prepared statements. I have since changed all PDO::PARAM_BOOL to PDO::PARAM_INT in my code as a workaround. Below is the test case I used to demonstrate to myself the broken behavior.

Test script:
---
<?php

$dns = "mysql:host=localhost;dbname=testdb";
$user = 'user';
$pass = 'pass';
$options = array(
    PDO::ATTR_EMULATE_PREPARES => false,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
);

$db = new PDO($dns, $user, $pass, $options);
$db->query("DROP TABLE IF EXISTS booltest");
$db->query("CREATE TABLE booltest (val BOOLEAN)");
$db->query("INSERT INTO booltest (val) VALUES (FALSE)");

$stmt = $db->prepare("SELECT COUNT(*) FROM booltest WHERE val = ?");
$stmt->bindValue(1, false, PDO::PARAM_BOOL);
$stmt->execute();

$count = $stmt->fetchColumn();
echo sprintf("count: %d\n", $count);

$stmt = $db->prepare("SELECT COUNT(*) FROM booltest WHERE val = ?");
$stmt->bindValue(1, false, PDO::PARAM_INT);
$stmt->execute();

$count = $stmt->fetchColumn();
echo sprintf("count: %d\n", $count);
---

Expected
---
count: 1
count: 1
---

Actual
---
count: 0
count: 1
---

All tests are on Fedora 20.

$ php -v
PHP 5.5.18 (cli) (built: Oct 16 2014 13:13:55) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

$ mysql --version
mysql  Ver 14.14 Distrib 5.5.38, for Linux (x86_64) using readline 5.1

I'm surprised at the comment above:

"You filed the bug against PDO_MySQL. From PDO_MySQL perspective it is a feature request. If it was filed against PDO, I'd call it a bug."

The goal of a bug reporting system is to get things fixed.  If it was filed against the wrong package then it should be reassigned, not demoted to a "feature request".

This bug was filed against 5.4 but I verified today that it still exists in 7.0.  It is probably the same as #38386 (https://bugs.php.net/bug.php?id=38386)

Looks like this issue has been fixed by https://github.com/php/php-src/commit/7d1aa7534d756477d45f8fa63b5467589ccca031 quite a while ago.