ASM Community

Interesting!

Duplicated here, Win7-64 .

#include <windows.h>
#include <stdio.h>

#define lengthof(x) sizeof(x)/sizeof(x[0])

char *source = "halløj æøåÆØÅ!";

int main()
{
	WCHAR	dest[100];

	memset(dest, '@', sizeof(dest));
	MultiByteToWideChar(CP_ACP, 0, source, -1, dest, lengthof(dest));

	FILE *f = fopen("out.bin", "wb");
	fwrite(dest, 1, sizeof(dest), f);
	fclose(f);
}

I haven't been bitten by this bug since I tend to stay away from ugly NUL-terminated strings - I use bytelength-without-NUL for conversion, and keep my strings in std::string / std::wstring . But this is pretty nasty, MS should be contacted.

EDIT: as can clearly be seen from the attached screenshot, there isn't any problem, and there's a proper 16-bit NUL terminator - I'm a moron for a couple of hours after getting out of bed :)

It's clearly a bug since the NUL terminator *IS* processed, but only a single byte is output. Let me quote MSDN as well (emphasis mine):



I updated the code above to printf() the result of MBTWC, and it returned 15 - that's the length of the source string including the NUL char.

EDIT: It's Not A Bug^TM

Actually I do write code like that. The above code is the equivalent of doing a getline with the exception that it truncates to the maximum specified length instead of throwing a failbit error. Also, take a close look at the "regex" I'm using "%1024[^\n]", it effectively matches all characters except a newline meaning that even if the EOF is reached, it will have already made it's first match (either a valid token or '\n' forcing a return of 0). The only real case in which EOF would be returned by using this routine would be if a read error occurred.. So I suppose it is wrong on that behalf and would warrant something more like:

int x; char buf[1025];
buf[ (((x=(int)fscanf( fd, "%1024[^\n]", buf ))>0)?x:0) ]='\0';

However I've never personally had a case where the prior had failed.

That wouldn't include the NUL, then. Notice my code - I use -1 for the length, which according to MSDN: "If this parameter is -1, the function processes the entire input string, including the null terminator"... and results in a single NUL byte, not a NUL word as it's supposed to be.

EDIT: It's Not A Bug^TM

Synfire: getting EOF result value might be very unlikely, but it's not good practice not to handle it. Furthermore, what's with the (int) cast? - fscanf already returns int. And finally, fscanf returns the number of fields, not bytes, read... so you'll be getting your NUL terminator at index 1, not at the end of the string (at least that's consistent with MSDN, K&R and empirical testing).

PS: the single-line statement might be "cute", but personally I'd introduce an "int result" to keep the code clearer & cleaner. Sure, code increases to two or three lines, but I'm willing to sacrifice that for clarity.

Ultrano: perhaps you should re-read what MSDN has to say about the function?



In other words, passing strlen+1 or -1 as argument, you should get a NUL terminated output string. A 1-byte NUL isn't exactly appropriate for UTF-16 output.

EDIT: ...which is why it's good and correct that MBTWC outputs a 2-byte NUL :P

WinXP SP2:

.data
	z1 db "hello",0
	z2 dw 40 dup (0CCCCh)
.code
main proc
	invoke MultiByteToWideChar,CP_ACP,0,addr z1,-1,addr z2,40	
	movzx ecx,z2[10]
	print ecx ; ecx = 0	 *******
	ret
main endp

No problem here...

I typecast as an old habit. When I first started out with C I hated having issues with "converting types" when I knew good and well the values were essentially the same thing. So I got myself into the habit of typecasting any function in which I grab a value from.

As for the reason for the reduced one-liner, it has nothing to do with "cuteness" rather than what's actually generated. Whereas using the extended version (int result) generates a 144 byte <main>, the one-liner generated 134 byte <main> (built with GNU-C). Little optimizations like this are useful. I'm by far a C expert but I try to keep code size down as much as possible no matter what language I'm writing in.

Ugh... that's pretty bad coding practice. When the compiler tells you there's an issue, there's usually a reason for it (C++ and the PlatformSDK is painful, though - less so in C mode). But doing this as a general coding practice is bad.

You might want to move to a decent compiler, or at least a more recent version of GCC? With VC2008 (and also lot older versions, I expect) introducing the temporary variable results in exactly the same code as doing the one-liner.

Told ya :)
The beer is strong in us tonight :P

The whole world would collapse if that func was buggy in that way.