GCC does not warn for this: int main() { wprintf (L"%s", 5); } GCC should try converting the string to single-byte (e.g. to UTF-8, which would work for any wchar_t encoding in which 0-127 maps to char's encoding) and test the format string.
A patch was posted a while back: http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01579.html
Subject: Re: -Wformat does not work for wide strings In view of the removal of c4x support I don't now think any patch for this needs to address the format of STRING_CSTs for non-8-bit target bytes. But it should still have appropriate accessors for extracting bytes / multibyte characters / wide characters from strings (such that support for non-8-bit target bytes could be added to those accessors later), though without necessarily finding all existing code that should be using those accessors. See also bug 20110 on the format checking not allowing for the execution character set once it's extracted a character from the string. For wide characters it's -fwide-exec-charset that's relevant.
Confirmed.
*** Bug 53612 has been marked as a duplicate of this bug. ***
*** Bug 93406 has been marked as a duplicate of this bug. ***
I know nothing of the inner workings of gcc, but what I can imagine, is that to check a wchar_t string is easier than a char string, because some encodings may use variable length multibyte encodings that might, when looked as individual bytes, overlap the ASCII alphabet character encoding (UTF-8 does not, but I suspect others might), but wchar_t should not, i.e. 'd' can only be equal to L'd'. So I don't see why checking for wchar_t is not done (but I must miss a big point).