From 1b923cc70dbb65fb55d44d97177144a4e291cb4a Mon Sep 17 00:00:00 2001
From: Michael Orlitzky <michael@orlitzky.com>
Date: Wed, 1 Jul 2026 22:55:56 -0400
Subject: [PATCH] ext/iconv/tests/bug48147.phpt: blacklist unknown iconv

This test is for the behavior of iconv's magic "//IGNORE" suffix. The
output it expects appears to agree with POSIX 2024 even when the
underlying implementation (glibc) does not. A comment has been added
to this effect, and two calls to urlencode() have been removed so that
two (expected) errors are not swallowed.

Afterwards we blacklist the "unknown" ICONV_IMPL, with musl in mind.
Despite what POSIX says, support for //IGNORE is far from standard. We
are checking for morally-correct results, however, so we opt for a
blacklist rather than a whitelist of implementations.
---
 ext/iconv/tests/bug48147.phpt | 35 +++++++++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/ext/iconv/tests/bug48147.phpt b/ext/iconv/tests/bug48147.phpt
index ce304eecfb3c..a8676fec2750 100644
--- a/ext/iconv/tests/bug48147.phpt
+++ b/ext/iconv/tests/bug48147.phpt
@@ -2,17 +2,44 @@
 Bug #48147 (iconv with //IGNORE cuts the string)
 --EXTENSIONS--
 iconv
+--SKIPIF--
+<?php
+/*
+ * POSIX 2024 standardizes "//IGNORE" and says that it should ignore
+ * both invalid and untranslatable sequences. However... being in the
+ * standard does not make it standard. Musl's iconv() does not support
+ * "//IGNORE" at all, and will fail if you try. The documentations for
+ * the BSD and IBM implementations make no mention of it either.
+ *
+ * Since the expected output appears to agree with POSIX, we use a
+ * blacklist of implementations that do not (yet?) conform.
+ */
+if (ICONV_IMPL == "unknown") {
+    /* musl */
+    die("skip iconv implementation does not support //IGNORE");
+}
+?>
 --FILE--
 <?php
+/*
+ * POSIX says that when //IGNORE is specified, invalid bytes followed
+ * by valid bytes "shall not be treated as an error." GNU iconv does
+ * not follow this convention, but PHP does the right thing. In the
+ * examples below, invalid bytes in the middle of the string get
+ * dropped, and a string is returned. The two examples where the
+ * problem is at the end technically do not qualify for the "shall
+ * not" exception because there are no VALID bytes after the error. So
+ * PHP is morally correct in those cases to return an error (false).
+ */
 $text = "aa\xC3\xC3\xC3\xB8aa";
 var_dump(iconv("UTF-8", "UTF-8", $text));
 var_dump(urlencode(iconv("UTF-8", "UTF-8//IGNORE", $text)));
 // only invalid
-var_dump(urlencode(iconv("UTF-8", "UTF-8//IGNORE", "\xC3")));
+var_dump(iconv("UTF-8", "UTF-8//IGNORE", "\xC3"));
 // start invalid
 var_dump(urlencode(iconv("UTF-8", "UTF-8//IGNORE", "\xC3\xC3\xC3\xB8aa")));
 // finish invalid
-var_dump(urlencode(iconv("UTF-8", "UTF-8//IGNORE", "aa\xC3\xC3\xC3")));
+var_dump(iconv("UTF-8", "UTF-8//IGNORE", "aa\xC3\xC3\xC3"));
 ?>
 --EXPECTF--
 Notice: iconv(): Detected an illegal character in input string in %s on line %d
@@ -20,8 +47,8 @@ bool(false)
 string(10) "aa%C3%B8aa"
 
 Notice: iconv(): Detected an incomplete multibyte character in input string in %s on line %d
-string(0) ""
+bool(false)
 string(8) "%C3%B8aa"
 
 Notice: iconv(): Detected an incomplete multibyte character in input string in %s on line %d
-string(0) ""
+bool(false)