Regression: NumberFormatter::parse() error code 1 not U_PARSE_ERROR (9); pollutes intl_get_error_code (ext/intl/formatter)

[PurHur]

Category

stdlib · php-src-strict · ext/intl

Problem

On unparseable input, Zend NumberFormatter::parse() returns false, sets the formatter error to U_PARSE_ERROR (code 9) with message Number parsing failed: U_PARSE_ERROR, and leaves the global intl_get_error_code() at 0. This compiler returns false but uses code 1 (U_ILLEGAL_ARGUMENT_ERROR-shaped), prefixes the message with numfmt_parse:, and also writes the failure into the global intl error (code 1).

Probed 2026-07-24 — Zend 8.2.32 vs php bin/vm.php.

Repro	Zend 8.2+	VM (2026-07-24)
parse('not-a-number')	false	false
$f->getErrorCode()	9 (U_PARSE_ERROR)	1
$f->getErrorMessage()	Number parsing failed: U_PARSE_ERROR	numfmt_parse: Number parsing failed: U_PARSE_ERROR
intl_get_error_code() after	0	1

php-src reference

• php/php-src ext/intl/formatter/formatter_main.c / formatter_format.c — parse error status
• ICU U_PARSE_ERROR = 9
• Related formatters: Stdlib: NumberFormatter::formatCurrency()/parse()/parseCurrency() + attribute accessors missing after #5154 (ext/intl/formatter) #20728, Stdlib: pg_field_name()/pg_field_num()/pg_field_type()/pg_field_size()/pg_field_prtlen() missing (ext/pgsql/pgsql.c) #20703

PHP implementation target

• ext/intl NumberFormatter parse path (PHP) — map ICU parse failure to code 9 / message without changing Zend’s global-intl non-pollution for this API
• Expose/recognize U_PARSE_ERROR consistently with other intl status constants
• No new C

Repro

./script/docker-exec.sh -- bash -lc 'cat > /tmp/nf_parse_err.php <<"PHP"
<?php
$f = new NumberFormatter("en_US", NumberFormatter::DECIMAL);
$r = $f->parse("not-a-number");
var_export($r); echo "\n";
echo $f->getErrorCode(), "\n";
echo $f->getErrorMessage(), "\n";
echo intl_get_error_code(), "\n";
PHP
php /tmp/nf_parse_err.php; php bin/vm.php /tmp/nf_parse_err.php'

Done when

• Object error code 9 + Zend message text (no numfmt_parse: prefix drift)
• Global intl_get_error_code() remains 0 after failed parse (Zend match)
• Compliance .phpt under test/compliance/cases/
• php-src-strict; no php-compiler-strict shortcut

Maintainer note (2026-07-24)

Pillar 1 red (north-star5-fast 4f-m). Live probe vs Zend 8.2.32.

[PurHur]

claim: PHP Compiler STD Lib Advanced — batch (issues #22870, #22877, #22855, #22699) — queued after #22877

[PurHur]

Merged via #22975

Verification:

• php bin/vm.php test/repro/issue_22855_numfmt_parse_error.php → false / 9 / Number parsing failed: U_PARSE_ERROR / global 0
• vendor/bin/phpunit --filter numberformatter_parse_error (+ related parse) → OK (8)

Batch complete for this run: #22870, #22877, #22855 merged. #22699 remains queued for a follow-up.