0

I would like to refer to the test application code for 7zip

On the following line (Line 383):

SzArEx_GetFileNameUtf16(&db, i, temp); //Line 383, gets directory and filename

The uint16* value temp gets a reference expression to the filepath (which I assume is a string).

I have a const char, let's name it filePathToCheck that is basically a filepath name. What I want is a way to compare the filePathToCheck value with the temp value, so that I can "choose" the files I want to decrypt

My initial implementation was to get the Multibyte Value of temp but this gives an empty string, found in the method below:

WideCharToMultiByte(CP_UTF8,NULL,temp,sizeof(temp),testa /* char * */, 0, NULL, NULL);

when running the test application (arguments has been handled) the testa remains an empty string after the WideCharToMultiByte function. Am I in the wrong track altogether and I should have handled in another way?

Sample code because the minimum code is still too large

aeee98
  • 114
  • 10
  • For reference, it was meant to be made into a dll so I can't use the raw application. – aeee98 Mar 18 '16 at 07:20
  • WideCharToMultiByte works fine. You must be doing something wrong. Show a [mcve]. – David Heffernan Mar 18 '16 at 07:34
  • I think that the 6th parameter being a `0` makes the API to return the required size of the `testa` buffer. When this happens, the `testa` buffer is of no use. My suggestion is to use the API once more, but this time passing the previous call's return value as the 6th parameter `cbMultiByte`. My assumption is based on this line from MSDN `If this parameter is set to 0, the function returns the required buffer size for lpMultiByteStr and makes no use of the output parameter itself.` – ubuntugod Mar 18 '16 at 07:45
  • Doing so gives an access violation error, which makes sense since the number of bytes written is 4. Changing parameter 6 to 4 also gives the same error. – aeee98 Mar 18 '16 at 07:52
  • double : http://stackoverflow.com/questions/13279024/convert-a-uint16-t-to-char2-to-be-sent-over-socket-unix –  Mar 18 '16 at 08:12
  • `temp` is a pointer so you're passing `sizeof(UInt16*)` for the size parameter, which is completely wrong. If the string is zero-terminated and you want a zero-terminated string back, pass `-1`. – molbdnilo Mar 18 '16 at 08:16
  • @aeee98 Access violation error even after allocating the buffer size for `testa` using the return value before the 2nd call? – ubuntugod Mar 18 '16 at 08:31
  • never mind, I figured, @H. Guijt's answer was on point, I shouldn't use a `char*` but instead a char array large enough to store the result. – aeee98 Mar 18 '16 at 08:34
  • Glad that the solution was found. I actually meant that you should dynamically allocate the `testa` to the size returned from 1st call, then use that large enough buffer for the 2nd call. – ubuntugod Mar 18 '16 at 08:36

1 Answers1

1

sizeof(temp) return the size of uint *, which is either 4 or 8. What you want is either the length (in characters) of temp, or you can simply pass -1 if temp is null-terminated.

testa had better be an array of bytes (not a character pointer!) that is large enough. The next argument should not be 0, but sizeof(testa).

H. Guijt
  • 3,325
  • 11
  • 16
  • I am using a predefined char array to store this (eg: char testchar[128]), when comparing with a definite char pointer of variable length, do I need to "resize" the variables by copying the char array to a char pointer or is it unnecessary? – aeee98 Mar 18 '16 at 09:02
  • If you know for sure there is an upper bound on the length of the input, you can use a fixed-size destination buffer. If not, it gets a little more complex: you'll need one call to WideCharToMultiByte (with buffer length set to zero) to figure out the memory needed, then dynamically allocate that memory (you can use vector or a pre-allocated string, it doesn't have to be malloc or new[]), and then another call to WideCharToMultiByte to actually get the translated data. – H. Guijt Mar 18 '16 at 09:06