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. > 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 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
