# Making parse_ini_*() aware of types

- Thread: https://externals.io/message/76970
- Original archive: https://news-web.php.net/php.internals/76970
- Started by Tjerk Meesters on 2014-08-30T14:36:23+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #76970 — Tjerk Meesters — 2014-08-30T14:36:23+00:00

URL: https://externals.io/message/76970#76970

Hi internals,

I was going through the bug list and found this report:

https://bugs.php.net/bug.php?id=38409

It discusses the fact that `parse_ini_file()` and `parse_ini_string()` throw away type information; for instance, the flag “on” doesn’t translate into a bool(true) but string(“1”).

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’ve found a way in which this can be solved with a separate scanner mode; e.g.:

$data = parse_ini_file(‘/path/to/file’, 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-scanner-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’t benchmarked it, but the impact on performance should be quite minimal.

Thoughts?

---

## #77003 — Julien Pauli — 2014-09-01T11:08:41+00:00

URL: https://externals.io/message/76970#77003 · In reply to: #76970

On Sat, Aug 30, 2014 at 4:36 PM, Tjerk Meesters
<tjerk.meesters@gmail.com> wrote:
> Hi internals,
>
> I was going through the bug list and found this report:
>
> https://bugs.php.net/bug.php?id=38409
>
> It discusses the fact that `parse_ini_file()` and `parse_ini_string()` throw away type information; for instance, the flag “on” doesn’t translate into a bool(true) but string(“1”).
>
> 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’ve found a way in which this can be solved with a separate scanner mode; e.g.:
>
> $data = parse_ini_file(‘/path/to/file’, 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-scanner-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’t benchmarked it, but the impact on performance should be quite minimal.
>
> Thoughts?


+1 for me, this seems obvious.

Julien

---

## #77004 — Paul Dragoonis — 2014-09-01T11:24:35+00:00

URL: https://externals.io/message/76970#77004 · In reply to: #76970

Seems like a no brainer and since its gone through voting then you could go
ahead with it.


> Hi internals,
>
> I was going through the bug list and found this report:
>
> https://bugs.php.net/bug.php?id=38409
>
> It discusses the fact that `parse_ini_file()` and `parse_ini_string()`
> throw away type information; for instance, the flag “on” doesn’t translate
> into a bool(true) but string(“1”).
>
> 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’ve found a way in
> which this can be solved with a separate scanner mode; e.g.:
>
> $data = parse_ini_file(‘/path/to/file’, 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-scanner-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’t benchmarked it, but the impact on
> performance should be quite minimal.
>
> Thoughts?