Hello all,
While working on some issues in WordPress relating to displaying the configured
max upload and POST sizes I came to realize that PHP doesn't appear to expose
any way of knowing the value of a php.ini directive if that value is
interpreted as a numeric/long value (parsed via `OnUpdateLong` and
`OnUpdateLongGEZero`, see main/main.c). It will return the string value which
was configured and (such as `14m`) but not the internal value parsed from it
(such as `14680064`).
While I started porting `zend_atol` into WordPress to better interpret values
such as `14MB` (14680064) or `0x5teak_and_egg` (5368709120) or `03136k`
(1669120) I realized that it's not fully possible to do this, specifically when
the configured value would overflow when computing the byte-size suffix, such
as for `9223372036854775807g`, which I believe will have a different result on
different platforms.
Noticing a few issues surrounding `post_max_size` and friends, I suggest
introducing a new function which takes as its input a numeric string as would
be given in `ini_set( 'post_max_size', ... )` and returns the value that PHP
internally parses if it were set with that.
Applications could then read the configured value with certainty and wouldn't
have to duplicate and maintain the internal C code from `php-src` as user-space
PHP.
```
$post_max_size = ini_get( 'post_max_size' );
$post_max_size_bytes = ini_numeric_value( $post_max_size );
```
Posting here as my first message, thanks for your patience with my
unfamiliarity of the process and format. Would like to know your thoughts on
the new function and any ideas for a proper name as I don't particularly feel
like I have found a good one yet.
Recap of why this exists:
- Applications cannot currently know the configured value of `post_max_size`
- If an application wants to approximate that value it needs to replicate
internal C code from `php-src` but this will breakdown in
extreme-but-allowed cases.
- Knowing the configured values is important for communicating relevant and
related configuration settings to users and for internal logic. e.g. Show a
user how large of a file they can upload before uploading it and prevent them
in JavaScript from doing that.
- Of several approaches considered this was the simplest way I could find to
add functionality without implying much bigger changes. Complexity inherent
to working with these values is left in application code, but by exposing the
parsed "byte size," those applications can accommodate without having different
interpretations of the actual configured values.
Proposed in https://github.com/php/php-src/pull/8454
Related PR in WordPress, replicating the `zend_atol()` logic in user-space
https://github.com/WordPress/wordpress-develop/pull/2660
Thanks for the feedback!
Dennis Snell
dennis.snell@automattic.com
