RFR: 8232084: HotSpot build failed with GCC 9.2.1

[Kim Barrett]

> On Oct 11, 2019, at 3:29 PM, Chris Plummer <chris.plummer at oracle.com> wrote:
> 
> Hi Yasumasa,
> 
> A couple of comments on (B). First there is a typo in "stringop-truncatino". Second, can the macros be used just before and after the strncpy reference rather than around the whole function? It would clarify both that the strncpy use has these macros in place and that the macros are there for the strncpy. As it stands now, if you see the macro references it won't be readily obvious why they are there.
> 
> As for which I prefer, I'm leaning towards (A) for it's simplicity. Yes, I understands Kim's reason for opposing it, but (B) and (C) are no better in that regard. In all cases we are doing something that should be completely unnecessary to work around a gcc bug. I could see preferring (C) if we are concerned about this issue popping up in other places.
> 
> BTW, I had mentioned seeing another instance of this recently in a review I did:
> 
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029361.html
> 
> I was thinking of pushing back on having to fix a perfectly valid strncpy, and like Kim was not that happy about having to switch it to a memcpy. I considered suggesting disabling the warning but decided that for this one issue bowing to memcpy was probably best, so I never brought it up. So following along on those same thoughts, for your fix memcpy might be acceptable (it's just "one" case if we ignore already fixed cases), but disabling the warning is probably best if we think this is going to be an issue that continues to pop up.

Right now it seems to me that -Wstringop-truncation is seriously
buggy, both in the false positive and false negative directions.  This
seems to be true at least through 9.x for some recent x.  And all of
the occurrences of this warning in our code that I've heard of have
been false positives.  So I think this warning is not carrying its
weight, and I'd be okay with globally disabling it for now, pending
improvements in its implementation.  I'd also be okay with the local
pragma-based suppression approach.  I strongly dislike substituting
memcpy.

When taking the #pragma approach, the need to conditionalize for clang
points out that we currently treat clang as equivalent to gcc at that
level.  That probably ought to change, but that's a separate issue.

Since these strncpy vs -Wstringop-truncation problems seem to be
cropping up periodically, I suggest we add and use os::strncpy_s,
modelled on the C11 function of that name.  Doing so should be a
separate followup issue.