Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76970
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.51 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-ID: <2BBB5D80-5594-4F53-B507-4AD3BB03AE0A@gmail.com>
Date: Sat, 30 Aug 2014 22:36:23 +0800
To: PHP Internals <internals@lists.php.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Making parse_ini_*() aware of types
From: tjerk.meesters@gmail.com (Tjerk Meesters)

Hi internals,

I was going through the bug list and found this report:

https://bugs.php.net/bug.php?id=3D38409

It discusses the fact that `parse_ini_file()` and `parse_ini_string()` =
throw away type information; for instance, the flag =93on=94 doesn=92t =
translate into a bool(true) but string(=931=94).

The report has had 21 votes and an average score of 4.3 +- 0.7, so it =
seems to have some traction with users.


Simply changing this behaviour would cause BC, so I=92ve found a way in =
which this can be solved with a separate scanner mode; e.g.:

$data =3D parse_ini_file(=91/path/to/file=92, true, INI_SCANNER_TYPED);

A patch for the lexer can be found here, together with a simple test =
case:

=
https://github.com/datibbaw/php-src/compare/php:master...datibbaw:ini-scan=
ner-plus

It currently distinguishes between booleans, numbers and NULL (it was =
mentioned in the ticket by someone else, not entirely sure of its =
usefulness, though). I haven=92t benchmarked it, but the impact on =
performance should be quite minimal.

Thoughts?=