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.tew...@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
>
