[LibC] Feature request: add snwprintf_s or snwprintf function

[nmoreaud]

I am a C++ developer and I have been redirected to here by WG14.
While porting some Microsoft C++ code to the Linux platform, I have realized that while there are snprintf() and vsnprintf() functions for char*, there is no direct equivalent for wchar_t* in the C standard.

This function (snwprintf_s or snwprint / vsnwprintf) would greatly help us to write an efficient logger, compatible with printf syntax and wide strings. snwprintf_s is defined in Annex K of the C standard.

Do you think it could be added to LLVM C library?

Current alternative, swprintf(), doesn't accept NULL as an output argument, nor does it return the total expected size. We have to allocate a buffer of increasing size and hope that the formatting string and arguments are valid.
Emulation of snwprintf_s in our programs results in inefficient code.
I think snwprintf_s addition would be interesting to maintain the parity with existing char-based printf methods, and it would help us to make old code that targets Windows cross-platform.

Some background here:
https://en.cppreference.com/w/c/io/fwprintf#Notes
https://stackoverflow.com/questions/4107947/how-to-determine-buffer-size-for-vswprintf-under-linux-gcc
https://stackoverflow.com/questions/3693479/why-does-c-not-have-an-snwprintf-function
https://stackoverflow.com/a/46289793/3412316

Best Regards
Nicolas M

[llvmbot]

@llvm/issue-subscribers-libc

[kasperk81]

if possible, just use utf-8 / (multi-byte or regular) char on unix and windows (msvc's cl.exe /source-charset:utf-8 /execution-charset:utf-8) and you will save a lot of time and hassle.

otherwise, change the code to use utf-8 / (multi-byte or regular) char and use WideCharToMultiByte / MultiByteToWideChar on windows (whichever direction you need data to adapt).

[nmoreaud]

We cannot migrate to char so easily. The adoption of Microsoft Windows CP_UTF8 will help us for sure in a few years.
For C++, libfmt has an alternative implementation of sprintf compatible with wchar_t so I have a solution for my project.

However, I think that there is a hole in the C standard: despite having many variants, there is no wchar_t equivalent to snprintf, which is basic requirement for many programs. I'd rather use the standard library than fmt for such standard features.

[kasperk81]

there is a hole in the C standard

this is not the place to propose api for C standard. the right place is standard committee's mailing list: https://open-std.org/JTC1/SC22/WG14/www/contacts.html.

and as you can probably imagine, even if your proposal will get accepted, it won't arrive overnight; it will be in next standard in next few years followed by toolchains' adaptation of that standard (for contrast, msvc doesn't even support C20 standard yet and it was not until 2021? they completed C17 std.). so through switching to multibyte char for your project is non-trivial, it's something you can do today.

[nmoreaud]

Yes, WG14 is the right place and I have already contacted them. Here is their answer:

The C committee standardizes existing practice, and major platforms have not implemented snwprintf.
The closest thing that major platforms have implemented is snwprintf_s, which is in Annex K of the C standard (though it turns out that not as many platforms have implemented Annex K as the committee expected).
So, the way to get it standardized is to get major platforms to implement it.

[michaelrj-google]

Implementing snwprintf should be fairly straightforward with our existing printf code as a base, since all the code would need is to be modified to support wide characters. A bigger issue might be that currently our printf is incomplete since I still need to finish some of the floating point handling. Regardless, if you want to try adding snwprintf to our libc feel free to send the patches to me.

[nmoreaud]

Ok, I will do this as soon as I have time.

[nmoreaud]

Sorry, I didn't have the opportunity to work on this, though I managed to make my team use std::string instead of std::wstring.
I close this ticket, because I don't think that I will have the time to make a good implementation.