This doesn't sound like a bug, it is possible for false to be interpreted as null rather than 0. You can probably do something like this to get 0(adjust according to your actual code):

Script:
---------------------
$data = array('name'=>'foo', 'active'=> (int)false);
$f = fopen('php://memory', 'r+');
fputcsv($f, $data);
rewind($f);
echo stream_get_contents($f);

Result:
--------------------------
foo,0

Indeed, this is not a bug, since (string)false === ''.
The docs could be improved in this regard, though.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Yeah, sure `(string)false === ''`. But `(string)null === ''` too! So if you have a nullable boolean field in your database, this function becomes completely useless, since you can't tell `null` from `false`.

Fixing the documentation is certainly better than nothing (haven't seen it live, though). But I'd suggest to add an optional argument to configure how `false` is treated - something like the $options constants in `json_encode()`.

> So if you have a nullable boolean field in your database, this
> function becomes completely useless, since you can't tell `null`
> from `false`.

And you won't be able to distinguish either from an empty string.
CSV knows nothing about NULLs and booleans – it's all about
strings. You have to cater to that yourself in any way that suits
your use-case.

> But I'd suggest to add an optional argument to configure how
> `false` is treated - […]

In my opinion, adding yet another optional argument to fputcsv()
does more harm than good.  However, feel free to start the RFC
process[1]. :)

[1] <https://wiki.php.net/rfc/howto>

> And you won't be able to distinguish either from an empty string.

Well, an empty string is not possible in a boolean field ;-)

> In my opinion, adding yet another optional argument to fputcsv()
does more harm than good.

Why? Which harm?

> CSV knows nothing about NULLs and booleans – it's all about
strings

Just reasoned about this some more. And I came to the conclusion that it isn't true ;-)

CSV (and `fputcsv()`) does have a distinction between strings and numbers: the quotes! `true` is exported as `1`, not as `"1"`. Why?? => The only possible answer I see: Because it's casted to `int` (not to `string`).

Well, and if you cast `false` to an `int`, what do you get? => `0`!

> CSV (and `fputcsv()`) does have a distinction 
> between strings and numbers: the quotes! `true` 
> is exported as `1`, not as `"1"`. Why?? => The 
> only possible answer I see: Because it's casted 
> to `int` (not to `string`)

you don't understand how PHP works

php > echo (string)true;
1
php > echo (string)false;
php >

You don't understand what I mean ;-)

php > echo (int)true;
1
php > echo (int)false;
0

but csv is all about TEXT and not numbers, so there is no point that something is casted to int - if you want 

http://php.net/manual/en/language.types.type-juggling.php
if you want to avoid this you have to cast your values explicit, that's it

> CSV (and `fputcsv()`) does have a distinction between strings and numbers: the quotes! `true` is exported as `1`, not as `"1"`. Why?? => The only possible answer I see: Because it's casted to `int` (not to `string`).

Such a distinction does not exist. The quotes are not part of the string (unless you explicitly include them), so obviously they will not be printed. In PHP, (string)false=="". That may or may not be a good choice, but it's the way it is and not going to change. fputcsv() does nothing more and nothing less than a simple string cast before printing the value. If you want to deviate from the standard string casting logic, you need to do so yourself.

and if you want to distinct between false and NULL you have to be prepared to do that by hand anyways in the export as well as in the import because your "So if you have a nullable boolean field in your database, this function becomes completely useless, since you can't tell `null` from `false`" is pointless too

php > echo (int)false;
0
php > echo (int)NULL;
0

> The quotes are not part of the string

Yeah, you're right, sorry! The quotes are added only if the string contains special characters.

> echo (int)NULL;

Yeah ;-)

But let's see it from a different perspective:
In the database, we have three possible values: true, false, null
In the CSV file, we have three options: 1, 0, nothing

I guess we all agree that the current mapping isn't quite smart:
true => 1
false, null => nothing

So what I'm asking for is *some* way to get:
true => 1
false => 0
null => nothing

> I guess we all agree that the current mapping isn't quite smart

no, because there is no mapping at all, it's that easy
that's how implicit type casting works

if you touch that here and make special cases you open a can of worms