Code Review fix for 8005044 remove crufty '_g' support from HS runtime code

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Dec 18 14:57:20 PST 2012


Adding back in the other aliases...

Harold,

The equivalentof:

     snprintf(buf, n, str);

is:

     strncpy(buf, str, n - 1);
     buf[n - 1] = '\0';

because snprintf() will only write out (n-1) bytes from
'str' to 'buf'and then write a NUL in the lastslot.
strncpy() copies up to 'n' bytes from'str'to 'buf'.
strncpy() will not copy past aNUL character in'str', but
it will also not NULterminate 'buf' if a NULis not found
in 'str'before the limit 'n' is reached.

Dan


On 12/18/12 2:48 PM, harold seigel wrote:
> Hi Ron,
>
> I think these calls to snprintf() in os_solaris.cpp and the other 
> os_....cpp files could be replaced with calls to strncpy().  It might 
> be a little simpler.
>
> Otherwise, it looks good.
>
> Thanks, Harold
>
> 2539 if (0 == access(buf, F_OK)) {
> 2540 // Use current module name "libjvm.so"
> 2541 len = strlen(buf);
> 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");*
> 2543 } else {
> 2544 // Go back to path of .so
> 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 }
>
> On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I'm sponsoring this code review request from Ron Durbin. This change
>> is targeted at JDK8/HSX-25 in the RT_Baseline repo.
>>
>> Dan
>>
>> Sending again with correct subject line, bug URLs and webrev URL.
>>
>>
>> Intro:
>>
>> This set of changes removes the runtimesupport for generation of 
>> debug versions that follow _g semantics.
>>
>> Defect:
>> JDK-8005044 remove crufty '_g' support from HS runtime code
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044
>> https://jbs.oracle.com/bugs/browse/JDK-8005044
>>
>>
>> Webrev
>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0
>>
>>
>> Details:
>> Files have been modified to remove all reference and support for 
>>  debug versions that follow _g semantics.
>>
>> Testing:
>>
>> Passed JPRT last night:
>>
>> Additional Testing In process: (suggested by Dan):
>>
>> src/share/vm/runtime/arguments.cpp
>>     - test with shared archive creation and use; see the e-mail
>>       from Coleen
>>
>> src/share/tools/ProjectCreator/ProjectCreator.java
>>     - just a usage message; visual inspection of the code
>>
>> src/os/windows/vm/os_windows.cpp
>>     - comments only; no testing needed
>>
>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp
>>     - the only code changes come into play when the "gamma"
>>       launcher is used
>>     - and when JAVA_HOME refers to a valid JDK, the function
>>       fakes up a JVM path so that callers using the JVM path
>>       to find other things in the JDK will work.
>>     - I can't find any way that the actual JVM path value
>>       that is returned is exposed
>>     - I don't see a way to test this other than have a debug
>>       printf() or manual code inspection.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/b78922f5/attachment.html 


More information about the hotspot-runtime-dev mailing list