On Tue, Jun 23, 2026 at 2:48 AM Kirill Makurin <[email protected]> wrote:
> (Please keep Pali CC'd as he's not subscribed to the list) > > Nikolay Sivov <[email protected]> wrote: > > > On Mon, Jun 22, 2026 at 8:32 PM Pali Rohár <[email protected]> wrote: > >>This WideCharToMultiByte() function and its API is insane. I did not > >> though about these new issues. Now I must admit that this code is too > >>complicated. > > > > I don't think it needs to be that complicated. > > > > If you have null terminated source buffer and fixed size destination, > you'd use: > > > > WideCharToMultiByte(CP_ACP, 0, src, -1, dest, dest_size, NULL, NULL); > > > > This will write up to "dest_size" to output, but it will write partial > output too. > > This is basically what my original version did, except it needed to > gracefully handle case when `WideCharToMultiByte` fails with > `ERROR_INSUFFICIENT_BUFFER`. > > It is useful to know that `WideCharToMultiByte` actually writes partial > output to the buffer; this information may come in handy. > If you allocate the size that this function tells you to, it's not going to be insufficient. If you can't allocate and have to use fixed buffer, you still know exactly if it's enough or not in advance. > > > If you want to allocate, you'll do: > > > > dest_size = WideCharToMultiByte(CP_ACP, 0, src, -1, NULL, 0, NULL, NULL); > > dest = malloc(dest_size); > > WideCharToMultiByte(CP_ACP, 0, src, -1, dest, dest_size, NULL, NULL); > > Yes, this is how you normally use it. The issue with _wassert() is that we > use `alloca` to allocate buffers, and we must limit their size to decrease > possibility of stack overflows. > > The rationale for using `alloca` was explained in the original message for > the first version of changes, and in the commit message. > > - Kirill Makurin > _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
