Patch for Review: JvGetStringUTFChars
Bryce McKinlay
bryce@mckinlay.net.nz
Wed Aug 13 13:30:00 GMT 2003
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
More information about the Java-patches
mailing list