On Sunday 21 June 2026 10:53:34 Kirill Makurin wrote:
> Pali Rohár <[email protected]> wrote:
>
> > On Sunday 21 June 2026 09:57:27 Kirill Makurin wrote:
> >> The issue with `min(output_from_WideCharToMultiByte, BUFSIZ)` is that if
> >> we end up passing BUFSIZ to `WideCharToMultibyte`, it may end up writing
> >> less bytes that `BUFSIZ`; for example, if it cannot fit a multibyte
> >> character into buffer. Those few bytes in the end of the buffer will have
> >> random values from the stack.
> >
> > The WideCharToMultiByte is returning length which is number of
> > filled bytes in output buffer. We should use this return value to
> > properly fill the nul term after the last filled byte and then it should
> > be safe. Moreover it always a good idea to fill that nul term after the
> > WideCharToMultiByte call as it does not have to fill it automatically.
> >
> > So the idea is:
> >
> > 1. Call WideCharToMultiByte to just calculate length of buffer required
> > to convert all characters.
> >
> > 2. Reduce the calculated length of buffer to BUFSIZ if it is larger.
> >
> > 3. Allocate buffer on stack of length from step 2.
> >
> > 4. Call WideCharToMultiByte to do actual conversion with the output
> > buffer length from step 2 to the buffer from step 3. It will return
> > number of written bytes.
>
> For whatever reason I thought it always returns full length of converted
> string and not number of bytes written to the buffer. I think some other
> function had this behavior, and I mixed them up.
Now I hope that I wrote the correct information that it returns the
number of written bytes and not full length. At least this is how I used
the WideCharToMultiByte more times...
But the API of those functions is really a mess. Some of them returns
full length with nul term, some full length without nul term and some
number of bytes written without nul term. So mixing of it is not a
surprise. So maybe it would be better to recheck usage of
WideCharToMultiByte.
> > 5. Fill the nul term after the last written byte determined from step 4.
> > (In case the last written byte was at the last byte of buffer then
> > write hat nul term at the last byte of buffer.)
> >
> > I quite do not see where is problem with usage of uninitialized (random)
> > values from stack/buffer. Even if it writes less bytes into output
> > buffer we still properly fill the nul term.
>
> Ok. I'll send new version of third patch later.
>
> - Kirill Makurin
Basically I have done that in the fixup which I sent, so you can reuse
parts of it. And now I see that I did here a -1 bug.
Together with "..." idea this is fix diff:
diff --git a/mingw-w64-crt/misc/wassert.c b/mingw-w64-crt/misc/wassert.c
index 2ad741191925..0023d47a4c27 100644
--- a/mingw-w64-crt/misc/wassert.c
+++ b/mingw-w64-crt/misc/wassert.c
@@ -33,10 +33,13 @@ static void conv (char *buffer, int buffer_size, const
wchar_t *wcs, unsigned cp
int length = WideCharToMultiByte (cp, 0, wcs, -1, buffer, buffer_size,
NULL, NULL);
if (length <= 0)
buffer[0] = '\0';
- else if (length >= buffer_size)
+ else if (length >= buffer_size) {
+ buffer[buffer_size-4] = '.';
+ buffer[buffer_size-3] = '.';
+ buffer[buffer_size-2] = '.';
buffer[buffer_size-1] = '\0';
- else
- buffer[length-1] = '\0';
+ } else
+ buffer[length] = '\0';
}
static int convsize (int max_buffer_size, const wchar_t *wcs, unsigned cp) {
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
