Say the string is \377\000, basename will use mbrlen() to check whether
it's a start of a multibyte sequence. While on Linux it'll return -1 for
any char in the extended ASCII, on Windows it's returning 1. From what I
see the reason is that Windows doesn't implement UTF-8 in the CRT lib,
it's rather 16-bit Unicode or DBCS. Since extended ASCII is convertable
to Unicode directly - thus the behavior. On Linux however, it's a true
UTF-8 locale and implementation, for it \377\000 is invalid.
Maybe mbrlen needs an independent implementation for Windows supporting
UTF-8. For now I just split out this case so the most of the big basename
test doesn't fail on this one case.
--- /dev/null
+--TEST--
+Test basename() function : usage variations with invalid paths
+--SKIPIF--
+<?php
+if((substr(PHP_OS, 0, 3) == "WIN"))
+ die('skip not for Windows"');
+?>
+--FILE--
+<?php
+/* Prototype: string basename ( string $path [, string $suffix] );
+ Description: Given a string containing a path to a file,
+ this function will return the base name of the file.
+ If the filename ends in suffix this will also be cut off.
+*/
+
+var_dump(basename(chr(-1)));
+
+echo "Done\n";
+
+--EXPECTF--
+string(0) ""
+Done
--- /dev/null
+--TEST--
+Test basename() function : usage variations with invalid paths
+--SKIPIF--
+<?php
+if((substr(PHP_OS, 0, 3) != "WIN"))
+ die('skip Run only on Windows"');
+?>
+--FILE--
+<?php
+/* Prototype: string basename ( string $path [, string $suffix] );
+ Description: Given a string containing a path to a file,
+ this function will return the base name of the file.
+ If the filename ends in suffix this will also be cut off.
+*/
+
+var_dump(basename("\377"));
+
+echo "Done\n";
+
+--EXPECTF--
+string(1) "%c"
+Done
array(""),
array(''),
array(NULL),
-
- /* invalid paths */
- array(chr(-1)),
);
function check_basename( $path_arrays ) {
--Iteration 48--
string(0) ""
-
---Iteration 49--
-string(0) ""
Done