Re: Patch: New version of "UTF-16 to 'Win32 locale' conversions"and filenames (replacing convertion tables with Win32 API calls)

[João Garcia <jgarcia at uk2 dot net>]

Hi Mohan,

Thanks for your comments!


> - It looks like the patch has a lot of code duplication. What are
>  your thoughts as far as refactoring the string conversion into a
>  reusable helper function.
>  
I am aware of the limeted scope of this patch.
I like the idea of "reusable helper functons", since this is not the 
only place where this kind of character-convertion is necessary.
But first it would be nice to find a pratical strategy to solve the 
generic problem of character-convertion on several platforms (and not 
only to solve filename problems)...

> - In a previous post, you had mentioned submitting a patch which
>  uses the native Unicode Win32 calls on non-Win9X, yet this patch
>  doesn't seem to do that. Did you have a change of heart?
>  
No, I didn't. But the right place to solve that problem is not only on 
natFile*.cc sources...
This is only another piece of the puzzle (may be a useless one, but I 
have my reasons to call your attention to those Win32 API functions...).

I like the generic proposal made by Bryce McKinlay in this post:
http://gcc.gnu.org/ml/java-patches/2003-q3/msg00389.html
And it would be nice to have more people writing comments on this subject...

In systems with iconv and using localized 8-bit codes, everything seems 
straight forward.
For me, the Win32 portion of the problem is the worst part... As you 
know, I would like to keep Win9X working (and without the use of 
unicows). If the option is to call WideCharToMultiByte() and 
MultiByteToWideChar(), then (*almost*) everything is solved...
But there is an alternative to this aproach: to patch all 
windows-specific native sources to use wchar and W-funtion calls to the 
Win32 API. This would break the support to Win9x branch (without the use 
of unicows -- iconv is not an alternative here) unless we would opt for 
code duplication (simultaneous support for A and W funtions -- it is 
easy to do it, but I can see *a lot* of resistance against it)... And 
this second strategy would not solve some specific situations where 
character-convertion is still necessary.
I don't know if Linux supports (or is going to support) wchar strings 
for filenames. If so, it is possible that similar compatibility issues 
would also arise there...


I would like to know if:
1- is it acceptable to use those "multibyte" functions for the Win32 
convertions?
2- is it acceptable to specialize those helper character-convertion 
functions by platforms, using wrappers to put system-specific API calls 
(if not, please propose some alternative)?
3-are there other platforms  that do not support iconv as a default?

> - What are your future plans with this? In particular, do you plan to
>  submit a patch against 3.4?
>  
It is easy to submit a temporary patch against 3.4. But that would only 
be useful to the comunity if someone would provide binaries that would 
use it...
So, I would be more motivated to cooperate in the process of solving the 
more global character-convertion problem.

> - Do you have any testcases?
>  
I don't have a specific one at the moment. But it is easy to propose one 
(or more, if necessary).

João