RFR: JDK-8007607

[Valerie (Yu-Ching) Peng]

Right, the important thing is to throw OOM to indicate the memory 
allocation failure.
The return value won't matter. If the caller is a Java method, an OOM 
will occur when returning from this JNI call. If the caller is another 
JNI method, then the caller should check for pending error condition, 
i,e.  by calling (*env)->ExceptionCheck(env), and do necessary cleanup 
before returning to its caller. The pending exception will be thrown 
when returning to Java method.

Valerie
On 02/08/13 09:38, John Zavgren wrote:
> Although I agree that the name: "GSS_C_NO_CHANNEL_BINDINGS" is misleading,
> I can't identify anything else that seems more appropriate.
>
> The header file:  
> /jdk8-tl/jdk/src/share/native/sun/security/jgss/wrapper/gssapi.h 
> defines GSS_C_NO_CHANNEL_BINDINGS as follows:
> #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
>
> The symbol matches the prototype of the function:
>
>     */*
>      * Utility routine which creates a gss_channel_bindings_t structure
>      * using the specified org.ietf.jgss.ChannelBinding object.
>      */
>     gss_channel_bindings_t getGSSCB(JNIEnv *env, jobject jcb) {
>       gss_channel_bindings_t cb;
>       jobject jinetAddr;
>       jbyteArray value;
>
>       if (jcb == NULL) {
>         return GSS_C_NO_CHANNEL_BINDINGS;
>       }
>         cb = malloc(sizeof(struct gss_channel_bindings_struct));
>
>         if(cb == NULL)
>             return  GSS_C_NO_CHANNEL_BINDINGS;*
>
> There doesn't appear to be anything in our set of options that is more 
> suggestive of a memory allocation failure and the symbol: 
> GSS_C_NO_CHANNEL_BINDINGS seems to be logically correct.
>
> Ideas?
>
> On 02/06/2013 04:57 AM, Dmitry Samersoff wrote:
>> John,
>>
>> Not sure GSS_C_NO_CHANNEL_BINDINGS; is correct return value for this case.
>>
>> I'm second to Valerie - it's better to throw OOM
>>
>> -Dmitry
>>
>>
>> On 2013-02-06 03:44, John Zavgren wrote:
>>> Greetings:
>>>
>>> I modified the native code to eliminate potential memory loss and crashes by checking the return values of malloc() and realloc() calls.
>>>
>>> The webrev image of these changes is visible at:
>>> http://cr.openjdk.java.net/~jzavgren/8007607/webrev.01/
>>>
>>> Thanks!
>>> John Zavgren
>>>
>
>
> -- 
> John Zavgren
> john.zavgren at oracle.com
> 603-821-0904
> US-Burlington-MA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20130208/628a4a99/attachment.htm>