Note that the correct (although MS proprietary) syntax for the case you mention is the upsized array
WCHAR
The compiler enforces the restriction that these fields must be the last member in a structure and that sizeof() does not include them. They are simply a synonym for basic pointer arithmetic (WCHAR*)((UINT_PTR)p + sizeof(struct))
The short version is that you have an array of size one, so one element was coppied
Sent from Surface Pro
From: xxxxx@spamcop.net
Sent: Monday, June 15, 2015 3:29 AM
To: Windows File Systems Devs Interest List
Vivek, “WCHAR[1]” defines a string precisely one character in length - that’s the significance of the 1. As soon as you try to write more than 1 character to it, you’re overflowing it (a “buffer overflow”, a common bug and security hole in general) - make the buffer the right size for the data it’s to hold, and check the length of string you’re trying to write to it.
You will often see “WCHAR[1]” inside Windows structure definitions where that string is at the end of a variable-size structure. That works because you effectively override the 1 when you allocate the size of the structure it’s in - but that isn’t what you’re doing here.
Your next problem is likely to be that sizeof(MessageCommand->Data) is not actually the size or length of the input string.
Note that the correct (although MS proprietary) syntax for the case you mention is the upsized array
WCHAR
The compiler enforces the restriction that these fields must be the last member in a structure and that sizeof() does not include them. They are simply a synonym for basic pointer arithmetic (WCHAR*)((UINT_PTR)p + sizeof(struct))
The short version is that you have an array of size one, so one element was coppied
Sent from Surface Pro
From: xxxxx@spamcop.net Sent: Monday, June 15, 2015 3:29 AM To: Windows File Systems Devs Interest List
Vivek, “WCHAR[1]” defines a string precisely one character in length - that’s the significance of the 1. As soon as you try to write more than 1 character to it, you’re overflowing it (a “buffer overflow”, a common bug and security hole in general) - make the buffer the right size for the data it’s to hold, and check the length of string you’re trying to write to it.
You will often see “WCHAR[1]” inside Windows structure definitions where that string is at the end of a variable-size structure. That works because you effectively override the 1 when you allocate the size of the structure it’s in - but that isn’t what you’re doing here.
Your next problem is likely to be that sizeof(MessageCommand->Data) is not actually the size or length of the input string.