Hi Matthias,
okay, if it is simplicity you are after, you could completely remove
the truncation handling too, since a buffer with 100 bytes leaves you
29 bytes for 29 digits; that is more than enough to display an int
even if it were 64bit (uint64 max = 18,446,744,073,709,551,615, 20
digits).
Bu
Chris
The test changes to support TLS1.3 have been pushed.
I noticed a small formatting issue in HttpRequest.java line 93
- unnecessary white space between the parentheses.
Thanks,
Michael.
On 16/06/2018, 09:22, Chris Hegarty wrote:
Hi,
This review request consists of a number of small API
Hi Thomas, I considered it but then I thought that the coding gets a bit
simpler with a fix buffer .
Best regards, Matthias
> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> Sent: Mittwoch, 20. Juni 2018 10:26
> To: Baesken, Matthias
> Cc: net-dev@openjdk.java
On 20/06/2018 09:07, Baesken, Matthias wrote:
Hello . Please review this small fix that fixes potential memory
leaks in getAdapter(s) in NetworkInterface_winXP.c and simplifies
the coding a bit too .
Currently when generating error messages , some memory is
malloc-ed for the e
Hi Matthias,
thanks, good catch about the leak.
But could you not just simply free the error_msg_buf after the call to
JNU_ThrowByName?
JNU_ThrowByName copies the message string, so no need to keep it alive
afterwards:
diff -r e810abb27deb
src/java.base/windows/native/libnet/NetworkInterface_wi
Hello . Please review this small fix that fixes potential memory leaks in
getAdapter(s) in NetworkInterface_winXP.c and simplifies the coding a bit too .
Currently when generating error messages , some memory is malloc-ed for
the error messages , but not always freed .
Bug:
https:
