Review for 8001185

[BILL PITTORE]

This bug deals with parsing sun.boot.library.path (dll_dir) when it has 
multiple paths. I found these problems while fixing JDK-7200297. The 
latter bug showed up on an embedded platform that does not have the 
ability to set LD_LIBRARY_PATH for shared library searches.
If you add -Dsun.boot.library.path=<dir> to command line you end up with 
dll_dir with multiple paths. When -agentlib option is used, code in 
os_<platform>.cpp splits out the individual paths and attempts to find 
the library in those paths. First problem is in os::split_path() where 
the incoming path is copied into a malloced buffer. Terminating null is 
not added. Result of this is that last path in list of paths will not 
get searched correctly (in os::dll_build_name()) since the snprintf will 
copy random amount of garbage after pathname. I supposes it's possible 
that reading way past end of malloc'd path could result in page fault if 
malloc'd memory at end of mapped memory block.
Another problem is that code in dll_build_name() leaves last full path 
attempted in the buffer that is returned to caller. Caller will then try 
to load that file even if dll_build_name() did not find the file. So one 
extra (possibly failing) load attempt.
Next problem is that dll_build_name could return NULL string (*buffer == 
'\0') if buffer too small or previous bug fixed. Caller should check for 
that otherwise (on linux/solaris) calling dlopen() with null string 
returns handle of executable; not what you're expecting. Changed the API 
for dll_build_name to return a bool so it is easy for caller to test 
whether or not returned buffer is valid.

Webrev is at:  http://cr.openjdk.java.net/~bpittore/8001185/webrev.00/

thanks,
bill