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.
