Hi internals, The filter_var functionality is one of the most efficient and well-known ways in PHP to validate and sanitize inputs for many use cases (e.g. FILTER_VALIDATE_INT for checking if a string is well-formed decimal input (or other bases), FILTER_VALIDATE_BOOL for user input/configs (cli/server api), FILTER_VALIDATE_URL, FILTER_VALIDATE_EMAIL).
The filter_var functionality is something that you can disable with --disable-filter, and I've often encountered code with a few dependencies or source files that assume that filter_var is always available when building php from source. ``` # Composer version 2.0.4 2020-10-30 22:39:11 sapi/cli/php ~/bin/composer.phar Fatal error: Uncaught Error: Call to undefined function JsonSchema\Uri\filter_var() in phar:///path/to/bin/composer.phar/vendor/justinrainbow/json-schema/src/JsonSchema/Uri/UriResolver.php # public function resolve($uri, $baseUri = null) # { # if (!is_null($baseUri) && !filter_var($baseUri, \FILTER_VALIDATE_URL) && .... ``` For me, the main reason why a developer/admin/hosting provider may want to disable the 'filter' module is 1. The filter_input() functionalities that allow direct access to the original POST/GET/COOKIE/ENV data. e.g. this makes code harder to test if the code or third party libraries it uses harder to unit test because $_GET/$_POST/$_COOKIE/$_ENV can't be replaced in filter_input. 2. The php build steps may have been carried over from PHP 5.2 when 'filter' was brand new and much less code used filter. 3. Desire for slightly smaller installations 4. Unaware of it since phpxyz-core and phpxyz-filter are different modules in an OS's package manager The filters themselves(https://www.php.net/manual/en/filter.constants.php) seem to be free of side effects glancing at the descriptions and implementation. The fact that filter_var isn't enabled by default may lead to 1. Application/library authors unconditionally using intval()/floatval() or other functions in core that don't check for unexpected suffixes (e.g. '10MB') Many languages have a function like atoi() that detects invalid integers 2. Applications skipping filtering steps if the function filter_var doesn't exist, e.g. allowing any string to be used as a url/email 3. Dependencies failing to run due to throwing Errors on rare configurations where filter_var is unavailable. It seems like filter is useful enough to already be statically compiled into the Windows builds published on windows.php.net ----- What are your thoughts on the following: Move the following functions into core and statically build them: (and all global `FILTER_*` constants but not `INPUT_*` from https://www.php.net/manual/en/filter.constants.php) - filter_has_var — Checks if variable of specified type exists - filter_id — Returns the filter ID belonging to a named filter - filter_list — Returns a list of all supported filters - filter_var_array — Gets multiple variables and optionally filters them - filter_var — Filters a variable with a specified filter Keep the following remaining functions in the 'filter' extension, continue enabling them by default and allowing --disable-filter to disable them: - filter_input_array — Gets external variables and optionally filters them - filter_input — Gets a specific external variable by name and optionally filters it Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php