[RFC] Exposed parsed value of php.ini numeric directives

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