RFR: JDK-8007607

[John Zavgren]

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/2c5117bd/attachment.htm>