Re: Patch for Review: JvGetStringUTFChars

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi Bryce,

>Sorry if it seems like I'm arguing against you all the time! ;-) I 
>don't mean to be the self-appointed libgcj code police or anything, but 
>I do feel this is an area where we need to be careful (especially where 
>it comes to the CNI interface)!

For the record, I appreciate the critique and value the character-building
experience - otherwise, I wouldn't be here. On this subject, I didn't realize
it would open up such a huge can of worms, but I really do appreciate
the rigor with which you're looking at this.

>> Would you be happy if I:
>
>> - rewrote the CNI function to do bounds checking, and
>
>That would be better, though there are still a few details to work out 
>- what happens if the user-supplied buffer turns out to be too small?

I thought about this too and had touched upon before. In the end,
this function seems more trouble than it's worth because you either
have to ignore any error (bad) or end up writing just as many lines
of code as before.

>Yeah. With it implemented as a macro, we can change the implementation 
>easily enough, so I am pretty happy with this idea - for internal use. 

I'd ideally like to put the helper class and macro in cni.h. If we're
supplying the other UTF8 functions anyway, the class and macro seem
incrementally better because they prevent unconditional heap
allocation or excessively large stack-allocated buffers.

>My only concern is that, in most of the cases where these UTF8 
>conversions are being done in libgcj, we really want to be able to 
>convert into any native character set, not just UTF - especially for 
>windows which afaik does not even use UTF8? So we'll really need 
>another API entirely.

This other API could also open up a can of worms. The MinGW
port has the issues you mentioned, as indicated here:

http://gcc.gnu.org/ml/java-patches/2003-q2/msg00328.html

...but I don't think that unconditionally going against libiconv is
the answer. MinGW doesn't use libiconv, and we probably
wouldn't need to for WinNT-based MinGW because we could
invoke the Unicode OS API directly.

In conclusion, shall I just cash in my chips, not touch cni.h and
simply submit a patch for jvm.h which uses the existing CNI
functions?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/