QUOTENAME considers 0xFFFF to be valid, but needs to return NULL if that character exists in input value
The QUOTENAME built-in function does not return NULL if the character U+FFFF (0xFFFF / 65535) is part of the string that is passed in. However, it should return NULL just like it does if character U+0000 is passed in. Those are the only two characters that are invalid in delimited identifiers, so QUOTENAME shouldn't reject one and not the other.
By not returning NULL if U+FFFF is found, the system stored procedure, sp_validname ( https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-validname-transact-sql ) will erroneously return 1 / true, even if U+FFFF is present in the name being checked (I will file a separate bug for that stored procedure since it can be updated to check for this code point and not rely on QUOTENAME for that).
SELECT QUOTENAME(N'a' + NCHAR(0x0000));
-- NULL (correct)
SELECT QUOTENAME(N'a' + NCHAR(0xFFFF));
-- a row is returned (oops!)
For details / research on valid/invalid characters, please see:
"The Uni-Code: The Search for the True List of Valid Characters for T-SQL Identifiers, Part 3 of 2 (Delimited Identifiers)" ( https://sqlquantumleap.com/2018/04/16/the-uni-code-the-search-for-the-true-list-of-valid-characters-for-t-sql-identifiers-part-3-of-2-delimited-identifiers/ )
Solomon Rutzky commented
Related bug report for "sp_validname":
sp_validname incorrectly returns 1 / true if name being checked contains code point U+FFFF which is invalid, even for delimited identifiers ( https://feedback.azure.com/forums/908035-sql-server/suggestions/37049194-sp-validname-incorrectly-returns-1-true-if-name ).