Unicode (wchar_t, TCHAR, functions) problems

[jpshortsuff]

Hi all.

I have decided to begin working with Unicode compatible programs and have started the process of easing my mind into the correct way of thinking for this task. Quite quickly I encountered a couple of issues that I couldn't seem to understand the cause of, so I am hoping that someone here can provide an insight. Thanks in advance for any help with these problems.

The first problem seems to relate to a simple concatenation of wchar_ts. Firstly, I have come to understand that (correct me if I'm wrong) TCHAR is infact a wchar_t if UNICODE is defined and so I have been using TCHAR extensively. All I am trying to do in this snippet is obtain the value of the %systemdrive% variable and pre-pend it to a file path.

Here is my first attempt:

TCHAR* sysdrive = new TCHAR[2];
ExpandEnvironmentStrings(L"%systemdrive%", sysdrive, 2);
log = _tcscat(sysdrive, L"\\Folder\\log.txt"); //this line causes program to crash, could be result of above line though?

Pretty much directly converted from the working char* version I have been using.

Having no idea what could be wrong on where the problem lies, I decided that the sysdrive is probably not going to be a Unicode character so I would see if it worked with a char* casted to a TCHAR*:

char* sysdrive = new char[2];
ExpandEnvironmentStringsA("%systemdrive%", sysdrive, 2);
log = _tcscat((TCHAR*)sysdrive, L"\\Folder\\log.txt"); //this line causes program to crash, could be result of above line though?

Still no luck. Since I am still in the first stages of non char characters and general Unicode API use there is probably something fundamental that I have missed, or it could be the (badly)self-taught C catching up to me.

Plugging on to the second identifiable issue with my program, I can't seem to work out how to compare my TCHAR*s correctly. Here is a comparison that just wont go:

if(_tcscmp(argv[1], L"/?")==0) //argv being the command parameters from main()

Simple stuff, just checking to see if someone used the /? command-line switch with my program. No joy with this one either (no crashes, just no joy).

If anyone can offer any help or advice with either of these issues, or point me in the direction of a good Unicode handling tutorial (or even both!) then I would greatly appreciative.

Thanks

[0xC0000005]

L"" is Unicode-specific and does not adapt to 'T' type when compiling. Use _T("") for strings.

TCHAR* sysdrive = new TCHAR[2];
ExpandEnvironmentStrings(_T("%systemdrive%"), sysdrive, 2);
log = _tcscat(sysdrive, _T("\\Folder\\log.txt")); //this line causes program to crash, could be result of above line though?

And make sure you are using _tmain() with TCHAR argv instead of main().

Don't ever cast a string to a TCHAR - it won't work when they are different types. You won't need the cast if you follow the instructions above.

This is certainly cause of the crash though:
TCHAR* sysdrive = new TCHAR[2];

It should be:
TCHAR* sysdrive = new TCHAR[MAX_PATH];

[jpshortsuff]

This is certainly cause of the crash though:
TCHAR* sysdrive = new TCHAR[2];

It should be:
TCHAR* sysdrive = new TCHAR[MAX_PATH];

Ok, looking back, 2 was horribly wrong, even my char version used 3. As far
as I can see, even in ASCII, %systemdrive% will never be more than two
characters long, so allowing an extra one of the terminating null that gives
a max length of 3. Converting to unicode, we have 3 (inc. null) characters
two bytes each giving a max of 6. This doesn't work, so my logic here must be
wrong. Assuming this to be wrong and taking a different approach, I tried
using the ExpandEnvStrings function to obtain the size required. Heres is my
code:

int i = ExpandEnvironmentStrings(L"%systemdrive%", NULL, 0);
TCHAR* sysdrive = new TCHAR[i+2];
ExpandEnvironmentStrings(L"%systemdrive%", sysdrive, i+2);
log = _tcscat(sysdrive, L"\\SysEcho\\DirLook.txt");

This still gives me error, until I add about 20 on to i. Is this not a valid
way of finding out how big the buffer needs to be?


Noted about _T and about _tmain(), however, I currently cant get _tmain or tmain to compile. This may well be something I have to sort out with my compiler (borland c++) so I will investigate more myself.

[0xC0000005]

Yes, that is a valid way of determinig the number of characters required for the environment string, but then you concatenate (append) "\\SysEcho\\DirLook.txt" (approximately 20 characters) to the buffer which is the cause of the overflow.

If this string is used in a local function I would simply allocate MAX_PATH and not worry about it. If you must store it in a global variable and are concerned about memory, then do a more careful calculation of how much memory will be required (or use a string class like std::string).

You still have not replaced L"" with _T("") which you will need to do.

I agree that _tmain() may be an issue with Borland, but if it supports TCHAR then it must support a 'T' main function. Keep looking. (Or maybe someone else can help).

[jpshortsuff]

Hi, sorry, I had changed L for _T but I pasted a older version.

I see what you mean about the buffer now, it all makes sense.

Found out about borland, just an added switch (-WU) allows Unicode and _tmain().

New (related question):
Quoted from MSDN (about FindFirstFile):

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 widecharacters, call the Unicode version of the function and prepend "\\?\" to the path. For more information, see Naming a File.

Does this mean that I have to hard-code 32767 for the real, unicode max path, or will it do it automatically when I prepend \\?\ and use MAX_PATH?

Thanks for your help

[0xC0000005]

If you use your method of setting the buffer size when calling ExpandEnvironmentString() you won't have a problem since that function could in some circumstances return a number larger than MAX_PATH - but you have it covered as long as you add enough for what you are going to append

I looked at the MSDN entry for FindFirstFile() and it appears that I would be getting in over my head if I tried to give a really accurate answer. Generally, I like to have enough personal experience with a variation of an API before I have confidence in what I say.

The FindFirstFile() entry contains a link to Naming A File. I would suggest that you read that first. After that, maybe someone else can help if you still have questions.

[jpshortsuff]

Ok, thanks again for your help.

All seems to be well at the moment, just having a problem compiling for _tWinMain in my second prog at the moment...

Cheers