|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #38409 parse_ini_file() looses the type of booleans
Submitted: 2006-08-10 10:42 UTC Modified: 2014-09-01 23:01 UTC
Avg. Score:4.2 ± 0.7
Reproduced:20 of 21 (95.2%)
Same Version:1 (5.0%)
Same OS:2 (10.0%)
From: yury at shurup dot com Assigned: datibbaw
Status: Closed Package: PHP options/info functions
PHP Version: 5.2.4-2ubuntu5.4 with Suhosin-Patch (cli) OS: Ubuntu 8.04.1
Private report: No CVE-ID:
 [2006-08-10 10:42 UTC] yury at shurup dot com

I have searched a bug database for the parse_ini_file keyword, but didn't find a releavant report submitted earlier. I am aware of bugs

but I am asking for another thing.

The problem is that in the described environment, PHP's parse_ini_file() function looses the type record for booleans and qualifies them either as an empty string for "false" or 1-char string (containing "1") for "true" instead of qualifying them as booleans as it is supposed to be (no relevant docs on this behaviour as well). 

If this is by design, then IMHO it is absolutely a subject to change and document in future PHP versions, because, YES, you can cast the type from string to bool, BUT what if you don't know that it IS a bool (parsing an abstract INI file)? 

After all, originally those INI-files came from Windows and everybody should treat them similar to the GetProfile... functions to avoid confusion (an unquoted boolean keyword like in the example below should remain a boolean, while quoted keyword should be treated as a string). In any case it wouldn't hurt and cause incompatibilies with older versions.

This is very annoying for someone writing a non-intrusive INI-file parser (which, e.g. would preserve comments, thus operating with parse_ini_file to read and the regular expressions to write out).

Reproduce code:

$stuff = parse_ini_file($file, true);

$a = array();
$a["foo"] = true;
$a["bar"] = false;

INI file

bar = false
quux = true

Expected result:
["bar"]=> bool(false)
["quux"]=> bool(true)

array(2) {
  ["foo"]=> bool(true)
  ["bar"]=> bool(false)

Actual result:
["bar"]=>  string(0) ""
["quux"]=>  string(1) "1"

array(2) {
  ["foo"]=> bool(true)
  ["bar"]=> bool(false)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-12-12 13:04 UTC] philipp dot kempgen at amooma dot de
Same problem on Linux and PHP 5(.1).
 [2008-12-12 13:14 UTC] philipp dot kempgen at amooma dot de
In addition to that I want NULL (unquoted) to be of type NULL.
Unquoted integers => int, unquoted floating point numbers =>
 [2008-12-12 14:43 UTC] yury at shurup dot com
It is very sad that this bug is still not classified, fixed and is perfectly reproducible after about 2 years since my original posting. I hope I would be able to hack on the sources some day but surely not during the next year to come.
 [2010-08-31 17:07 UTC] guy dot paddock at redbottledesign dot com
I also second the fact that parse_ini_file() should parse booleans as boolean types, rather than strings. In my application, the values returned from parsing the INI file are checked to ensure that they are the correct type (string, bool, int, etc). That way, if the user accidentally typed the wrong value in for a setting, they are presented with the appropriate error message, rather than having their value interpreted incorrectly.

Unfortunately, the way that parse_ini_file() parses booleans, it converts "TRUE" and "FALSE" into "1" or an empty string "", which means that is_bool() returns FALSE. I understand perfectly that is_bool() is intended only to determine if a variable really is a boolean -- my problem is not with that function. My problem is with parse_ini_file()'s counter-intuitive behavior of not parsing boolean values into a boolean type. Why else would we want it interpreting boolean constants in the first place?
 [2010-08-31 23:33 UTC] guy dot paddock at redbottledesign dot com
Hrm, it also looks like there's a similar problem for integers -- they become integer strings, so is_int() returns FALSE on them.

Why doesn't parse_ini_file() translate values to the appropriate type?
 [2011-04-08 20:49 UTC]
-Package: Feature/Change Request +Package: PHP options/info functions
 [2011-12-19 19:21 UTC] pwinnski at gmail dot com
PHP 5.3.6 on Centos. Still not fixed, so I must explicitly cast to boolean in the 
code that reads the ini file.
 [2012-03-15 10:17 UTC] adria dot cidre at gmail dot com
Still not working on Centos over PHP 5.3.10
 [2013-12-02 15:25 UTC] chudinov at yahoo dot com
Versions 5.4 and 5.5 have same problem.
It is quite annoying to cast that is true or false to actually boolean type!
 [2014-09-01 23:01 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: datibbaw
 [2014-09-01 23:01 UTC]
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at

 For Windows:
Thank you for the report, and for helping us make PHP better.

Fixed in repo:;a=commit;h=5270ee1aef83a4cd17dc1175052ab3b9da94717a

The changes are slated for 5.6.1 onwards.
 [2015-03-22 11:44 UTC] mruz at poczta dot onet dot pl
On the 5.6.6 I still have the problem.
 [2015-04-03 12:03 UTC] arjen at react dot com
You have to pass INI_SCANNER_TYPED as 3rd argument.


Documentation for this mode is missing.
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Feb 28 07:01:36 2017 UTC