Code Review Request: 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending
Valerie (Yu-Ching) Peng
valerie.peng at oracle.com
Fri Mar 21 21:48:55 UTC 2014
Max,
Thanks a lot for the review, please find comments in line.
Webrev updated: http://cr.openjdk.java.net/~valeriep/8031003/webrev.01
On 03/17/14 01:47, Wang Weijun wrote:
> NativeUtil.h:
>
> 88: How about puts(s) or printf("%s", s) (in case s includes "%")?
Sure.
> NativeUtil.c:
>
> 514-516: not necessary?
Ok.
> 539-543: Why not TRACEn here?
Didn't want to add TRACE4 just for this one call. Anyway, changed the
2nd one to just 3 arguments and used TRACE3 for both calls.
> 639-659: It looks like if cbytes == NULL then the function returns NULL with no exception throwing and this would break something in GSSLibStub.c. But actually cbytes will never be NULL there, right? How about remove the cbytes == NULL check at all?
Hmm, getJavaBuffer is an utility method, so supposedly, I think it's
reasonable to return NULL with no exception when cbytes is either NULL
or GSS_C_NO_BUFFER. So, I prefer to keep the check of cbytes == NULL
check since we have no control over the underlying native GSS lib. The
result of getJavaBuffer(...) calls are mostly returned as results. I'd
expect if the native buffer is null or empty, the error code should
indicate the cause and corresponding exception would be thrown.
> 644: I have no idea why cbytes->length != 0 is checked. Why cannot it be an empty string?
It's not that it can't be empty. But rather just that I don't see the
need to distinctish between NULL and byte[0] (yet).
> GSSLibStub.c:
>
> 92: This need not be a jboolean, just use an int.
>
> 536: I guess getJavaString on 529 already released outNameBuf?
Good catch, I missed this one when changing code back and forth.
> 1103: This is not only "cleanup", it is "error".
Agreed.
> 1105: Not safe to releaseName/releaseCred here?
I think it should be done but the earlier code isn't doing that. I've
added code to release srcName, targetName, and delCred if error is
encountered.
Thanks,
Valerie
>
> Thanks
> Max
>
>
> On Mar 15, 2014, at 6:11, Valerie (Yu-Ching) Peng<valerie.peng at oracle.com> wrote:
>
>> Max,
>>
>> Can you please help reviewing the fix for 8031003: [Parfait] warnings from jdk/src/share/native/sun/security/jgss/wrapper: JNI exception pending?
>>
>> I ended up re-factoring the code to clean things up. So, the changes are somewhat extensive. I have also replaced the debug callbacks with native printf calls.
>>
>> The webrev is:
>> http://cr.openjdk.java.net/~valeriep/8031003/webrev.00/
>>
>> Thanks,
>> Valerie
More information about the security-dev
mailing list