John Szakmeister wrote:
>On Tuesday 19 October 2004 12:43, Branko Čibej wrote:
>[snip]
>
>
>>>@@ -173,7 +175,15 @@
>>> apr_pool_create (&pool, 0);
>>> /* get exe name - our locale info will be in '../share/locale' */
>>> inwords = sizeof (ucs2_path) / sizeof(ucs2_path[0]);
>>>- GetModuleFileNameW (0, ucs2_path, inwords);
>>>+ if (! GetModuleFileNameW (0, ucs2_path, inwords))
>>>+ {
>>>+ CHAR ansi_path[MAX_PATH];
>>>+ GetModuleFileNameA (0, ansi_path, sizeof (ansi_path));
>>>+ MultiByteToWideChar (_getmbcp (), MB_PRECOMPOSED, ansi_path,
>>>+ lstrlenA (ansi_path), ucs2_path,
>>>+ sizeof (ucs2_path) / sizeof
>>>(ucs2_path[0]));
>>>
>>>
>>I'd just use svn_utf_cstring_to_utf8 here, and do the wide char to UTF8
>>conversion only for strings returned from the W variant of this
>>function.
>>
>>
>>
>>>+ }
>>>+
>>> inwords = lstrlenW (ucs2_path);
>>> outbytes = outlength = 3 * (inwords + 1);
>>> utf8_path = apr_palloc (pool, outlength);
>>>
>>>
>
>Is it really worth the effort? I mean, now we have an svn_error_t to
>handle, only we can't return that. So now we have to clear, set apr_err
>to something meaningful so we can error out later. I'm not sure it makes
>the logic that much cleaner to follow. In fact, I would say the
>opposite.
>
>If you think it is worth the effort, I'll make the changes... I just don't
>want to obfuscate what's really happening any more than necessary.
>
Now that I took a closer look at the surrounding code, I think the
current way is better, too.
>Also, do you know what the purpose behind this line is:
> utf8_path[outlength - outbytes] = '\0';
>
>I believe that it's trying to set a NULL character at the end of the
>string, which should really be:
> utf8_path[outbytes] = '\0';
>
>Or am I missing something?
>
>
Yes, you are. :-) After conversion, APR sers outbytes to the number of
bytes left in the buffer, not the number of bytes converted. That's
useful, because you can do several concatenating conversions in a row
into the same buffer without having to twiddle the outbytes parameter.
If that line of code were wrong, we'd definitely have noticed it before,
don't you think? :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 05:41:50 2004