[12] RFR: 8214777: Avoid some GCC 8.X strncpy() errors in HotSpot

[Kim Barrett]

> On Dec 11, 2018, at 4:44 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 12/11/18 1:27 AM, Kim Barrett wrote:
>>> On Dec 10, 2018, at 1:57 PM, Simon Tooke <stooke at redhat.com> wrote:
>>> 
>>> This small patch fixes some simple warnings in Hotspot code, found by
>>> GCC 8.1
>>> 
>>> Essentially, any code sequence of the pattern
>>> 
>>>   int l = strlen(somestring)
>>>   char* buffer = malloc(l + 1)
>>>   strncpy(buffer, somestring, l)
>>>   buffer[l] = 0
>>> 
>>> is replaced by
>>> 
>>>   int len = strlen(somestring)
>>>   char* buffer = malloc(len + 1)
>>>   strncpy(buffer, somestring, len + 1)
>>> 
>>> For xmlstream.cpp, this is actually a small inefficiency, as the null
>>> byte is immediately overwritten; but it makes GCC happy.
>> 
>> Why not just call strcpy, rather than strncpy, since the size is obviously sufficient.
> 
> I would advise against that. The word "obvious" in this context always makes me
> nervous because many bugs have been written when the programmer thought something
> was obvious.
> 
> I'd be happier if there were no calls to strcpy() anywhere. Any usage of it is
> a red flag.

FWIW, 370 calls in jdk, of which 160 calls are in src/hotspot.

The original pattern is ensuring the buffer has a terminating NUL, and
being blatant about it. The replacement pattern obscures that. I think
the replacement pattern is no more obviously correct than using strcpy,
and probably less obvious than disabling the warning for the original code.