Win32 strange widechar behavior

Question

I haven't used wide chars before. Here's the code from someone else:

char moduleFileName[512];
int size = ::GetModuleFileName(NULL,moduleFileName,sizeof(moduleFileName));
char c_drive[256];
char c_dir[256];
_splitpath_s(moduleFileName,c_drive,sizeof(c_drive),c_dir,sizeof(c_dir),NULL,0,NULL,0);
root = c_drive;
root.append(c_dir);

wchar_t moduleFileNameW[512];
int sizeW = ::GetModuleFileNameW(NULL,moduleFileNameW,sizeof(moduleFileNameW));
wchar_t w_drive[256];
wchar_t w_dir[256];
_wsplitpath_s(moduleFileNameW,w_drive,sizeof(w_drive),w_dir,sizeof(w_dir),NULL,0,NULL,0);
wroot = w_drive;
wroot.append(w_dir);

SEVEN_ZIP_EXE = wroot;
SEVEN_ZIP_EXE += L"\\7z.exe";

The point is to set a variable to where the 7z.exe file is. When I debug it on my Windows 7 Prof. 64 bit system I end up what look to me like invalid chars for wroot, e.g.

﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾﻾쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌쳌 Blockquote

One problem you have is using sizeof for the W functions. That is not good. They want the number of elements in the array not the size in bytes. — Jim Rhodes, Dec 03 '11 at 23:37
Why is all the widechar stuff neeeded anyway? Any reason I can't just calculate the path in the first block of functions? — fred basset, Dec 03 '11 at 23:43
The debug dump is trying to show you the Unicode glyph for 0xfefefefe. Plenty of meaning for that value: http://www.nobugs.org/developer/win32/debug_crt_heap.html — Hans Passant, Dec 04 '11 at 00:16
"쳌" is 0xCCCC and that is mostly because you haven't initialized the variables. 0xFE in the remaining part is buffer slack. It appears in [MSVC debug mode](http://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new) and is extremely useful to determine the bug when you see some "strange" values such as the string above, int3 (software interrupt), invalid access to address 0xCCCCCCCC, or 204, -858993460, etc... — phuclv, Aug 13 '14 at 10:32

score 0 · Answer 1 · answered Dec 03 '11 at 23:51

Change your sizeof's to _countof's and that will fix your strange data problem.

You don't need both sets of functions. Use whichever set is appropriate for the application. If you need SEVEN_ZIP_EXE to be a wstring, then you can eliminate the char stuff.

score 0 · Answer 2 · answered Dec 04 '11 at 00:23

0

The problem is sizeof, and if you really want to use this sizeof(w_dir)/sizeof(wchar_t)

I gather what you are trying to do is get the directory containing your executable. Rather than using the clumsy splitpath, I suggest the following:-

TCHAR   szBuff[FILENAME_MAX];
TCHAR   *ShortName;
GetFullPathName(moduleFileName, FILENAME_MAX, szBuff, &ShortName);
*(ShortName-1) = '\0';  // remove exe from path

szBuff will contain the directory, and ShortName points to the name.

The above code uses TCHAR and #define UNICODE, but you could change the functions names to the wchar names.

answered Dec 04 '11 at 00:23

Milliways

1,265
1
12
26

It is poor coding to use FILENAME_MAX in the function call. It is better to use the Microsoft defined macro on the variable, _countof(szBuff). That way if FILENAME_MAX has to be changed it doesn't need to be changed in multiple places. – Jim Rhodes Dec 04 '11 at 00:36
FILENAME_MAX is a system defined constant – Milliways Dec 04 '11 at 06:26
What if someone changes the size of szBuff to something other than FILENAME_MAX? What if an SDK update changes the value of FILENAME_MAX? – Jim Rhodes Dec 06 '11 at 03:38

Win32 strange widechar behavior

2 Answers2