RFR 8151788: NullPointerException from ntlm.Client.type3

[Pavel Rappo]

Hi Vyom,

I wonder if Max (the author of the original NTLM.java) has seen the fix? The
reason I'm asking is that when I see this

    byte[] readSecurityBuffer(int offset) throws NTLMException {
        int pos = readInt(offset+4);
*       if (pos == 0) return null;
        try {
            return Arrays.copyOfRange(
                    internal, pos, pos + readShort(offset));
        } catch (ArrayIndexOutOfBoundsException ex) {
            throw new NTLMException(NTLMException.PACKET_READ_ERROR,
                    "Input message incorrect size");
        }
    }

and this

*   // Some client create a alist even if server does not send
*   // one: (i16)2 (i16)len target_in_unicode (i16)0 (i16) 0
    byte[] alist = null;
    if ((inputFlags & 0x800000) != 0) {
        alist = r.readSecurityBuffer(40);
    }

It seems to me like we return null to work around it later with byte[0]. If so,
wouldn't it be any better to return byte[0] straight from readSecurityBuffer?

In other words, can we dig a bit deeper in order to make this awkward null
handling more natural?

P.S. I'm not an expert in this area, I may be easily saying something that
doesn't make much sense. Feel free to ignore it.

Thanks,
-Pavel

> On 12 Jul 2016, at 14:27, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> 
> gentile reminder.
> Vyom
> 
> On Thursday 30 June 2016 02:16 PM, Vyom Tewari wrote:
>> Hi All,
>> 
>> Please review the below simple fix.
>> 
>> Bug        : JDK-8151788  NullPointerException from ntlm.Client.type3
>> Webrev  : http://cr.openjdk.java.net/~vtewari/8151788/webrev0.0/index.html <http://cr.openjdk.java.net/%7Evtewari/8151788/webrev0.0/index.html>
>> 
>> Thanks,
>> Vyom
>