Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse

2014-03-04 Thread Chris Hegarty
On 4 Mar 2014, at 03:25, Ivan Gerasimov wrote: > Yes, you're right. > strtok() is thread-safe in Windows unlike its Unix counterpart. > > Thus using strtok_s() only adds some boundary checking in this case. Ivan, Are you now withdrawing this request for review? Or are you suggesting that st

RFR: 8025293 - JNI exception pending checks in java.net

2014-03-04 Thread Mark Sheppard
Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls in src/solaris/native/java/net/NetworkInterface.c src/windows/

Re: RFR: 8025293 - JNI exception pending checks in java.net

2014-03-04 Thread Chris Hegarty
This looks good to me Mark. Trivially, and it is more of a stylistic preference, towards the end of the Solaris NetworkInterface.c I would remove the if (ob) … else, and use CHECK_NULL_RETURN(obj, NULL). But, what you have is right, either is fine. -Chris. On 4 Mar 2014, at 11:06, Mark Sheppar

Re: RFR: 8025293 - JNI exception pending checks in java.net

2014-03-04 Thread Alan Bateman
On 04/03/2014 11:06, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls in src/solaris/nati

Re: RFR: 8025293 - JNI exception pending checks in java.net

2014-03-04 Thread Mark Sheppard
Chris, thanks for the response. I can use the common CHECK_NULL_RETURN convention if preferred. The reason I went with if ( name_utf != NULL) { ...} else { ...} is because the != NULL is the most likely code path in getByName. Nonetheless, I'll make the change for consistency. regards Mark

Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse

2014-03-04 Thread Ivan Gerasimov
VS compiler issues this warning on strtok() usage: : warning C4996: 'strtok': This function or variable may be unsafe. Consider using strtok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. So, the suggested fix can reduce number of complains from th

Re: RFR: 8025293 - JNI exception pending checks in java.net

2014-03-04 Thread Mark Sheppard
Hi Alan, thanks for the response. I originally had a CHECK_NULL_RETURN after getBraodcast and tests failed on Macos, but not on other platforms! The issue is that getBroadcast returns NULL when broadcast is not available for an interface, or when the ioctl calls return an error. The former i

Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse

2014-03-04 Thread Chris Hegarty
On 4 Mar 2014, at 11:52, Ivan Gerasimov wrote: > VS compiler issues this warning on strtok() usage: > > : warning C4996: 'strtok': This function or variable may be unsafe. Consider > using strtok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. > See online help for details. >

Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse

2014-03-04 Thread Ivan Gerasimov
Thank you Chris! On 04.03.2014 16:43, Chris Hegarty wrote: On 4 Mar 2014, at 11:52, Ivan Gerasimov wrote: VS compiler issues this warning on strtok() usage: : warning C4996: 'strtok': This function or variable may be unsafe. Consider using strtok_s instead. To disable deprecation, use _CRT_

Re: RFR: 8025293 - JNI exception pending checks in java.net

2014-03-04 Thread Alan Bateman
On 04/03/2014 11:54, Mark Sheppard wrote: Hi Alan, thanks for the response. I originally had a CHECK_NULL_RETURN after getBraodcast and tests failed on Macos, but not on other platforms! The issue is that getBroadcast returns NULL when broadcast is not available for an interface, or when th