php-src/ext/standard/tests/strings/basename_invalid_path_win.phpt

--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
exclude the platform diff case from the test 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. 2015-07-26 18:31:32 +00:00			`--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,`
Trim trailing whitespace in *.phpt 2018-10-14 15:45:48 +00:00			`this function will return the base name of the file.`
exclude the platform diff case from the test 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. 2015-07-26 18:31:32 +00:00			`If the filename ends in suffix this will also be cut off.`
			`*/`

			`var_dump(basename("\377"));`

			`echo "Done\n";`
			`--EXPECTF--`
			`string(1) "%c"`
			`Done`