RFR [XS]: 8235489: handle return values of sscanf calls in hotspot

[Kim Barrett]

> On Dec 6, 2019, at 10:17 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hello,  I noticed there are some remaining sscanf calls  in the hotspot codebase missing return value checks.
> Those should better be checked  .
> 
> 
> Bug/webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8235489
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8235489.0/
> 
> 
> Thanks, Matthias

------------------------------------------------------------------------------
src/hotspot/os/linux/os_linux.cpp  
2085       memset(name, 0, sizeof(name));

What is this line of the change for?  Is this because the pathname
field in a line can be blank?  That isn't sufficient.  That case needs
to be handled after the "if (matches < 6) continue;" line, e.g. check
whether matches == 6 (e.g. a blank name field), forcing "name" to be
blank if so (e.g. name[0] = '\0').  Otherwise, "name" will contain
data from the most recent parsed line that contained a match for that
field.

------------------------------------------------------------------------------
src/hotspot/os/linux/os_linux.cpp  
2083       char device[6];
...
2088       int matches = sscanf(line, UINT64_FORMAT_X "-" UINT64_FORMAT_X " %4s " UINT64_FORMAT_X " %5s " INT64_FORMAT " %s",

Good eye, spotting the mismatch between the declared size of device
and the size spec in the format string (e.g. changing "%7s" => "%5s").

------------------------------------------------------------------------------
src/hotspot/os/linux/os_linux.cpp 

In the sscanf format string, there's no length spec for the pathname,
e.g. it uses an unadorned "%s".  PATH_MAX doesn't deal with long file
names.

------------------------------------------------------------------------------