Re: Patch for Review: JvGetStringUTFChars

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Wednesday, Aug 13, 2003, at 22:58 Pacific/Auckland, Mohan Embar 
wrote:

> > JvGetStringUTFRegion cannot be safely used without a corresponding 
> > call
> > to JvGetStringUTFLength. If its being used somewhere without one then
> > that is a serious bug.
>
> > > - the _Jv_TempUTFString class and JV_TEMP_UTF_STRING macro
> > >   (subsequent patch) will also shield us from this
> >
> > Seems like these are two solutions to the same problem. Why do we need
> > both?
>
> You've argued me into a corner here.

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)!

> 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?

But I guess if Tom thinks this function is a good idea, and it is made 
safe wrt bounds checks, then I am ok with it.

> - rewrote _Jv_TempUTFString to use the old CNI functions
>   to avoid the additional call to JvGetStringUTFLength?

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. 
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.

Regards

Bryce