RFR: 8u: 8076475: Misuses of strncpy/strncat

[Andrew Haley]

On 4/3/20 4:44 AM, Andrew Hughes wrote:
>
> On 02/04/2020 09:36, Andrew Haley wrote:
>> On 4/1/20 6:54 PM, Andrew Hughes wrote:
>>> * src/share/vm/runtime/os.{c,h}pp
>>>   If we're going to add strdup_check_oom, I think this should be done by
>>> backporting JDK-6424123 [1] so it's used consistently throughout the
>>> codebase rather than just the two call sites in this patch.
>>
>> I strongly disagree that we should import such a patch into JDK 8 for
>> this reason.
>>
>> It's a judgement call, of course. We have two desiderata here: those
>> of consistently backporting patches and minimizing changes. As JDK 8
>> matures, minimizing change has become more and more important, and it's
>> perfectly OK to snip small fragments of patches such as this in order
>> to minimize change.
>>
>> Of course I'm aware of the other side of the argument, but I don't
>> think it's as important.
>
> And I strongly disagree with turning 8u into a unmaintainable mass of
> partial chunks of code from various changesets.

I have no intention of doing that, but pulling in large and otherwise
unnecessary changesets for single functions should not be done in a
release of a mature product.

Here is my reasoning. The need for stability and the minimization of
churn increases over time. People use JDK 8 because they want that
stability, and every patch carries some risk. So, ecause it is now a
mature piece of software, patches should be minimal where they
reasonably can. The practice of, by default, pulling in dependencies
from later releases is too risky: they might well be broken in ways
that the old version wasn't, and they may depend on other changes in
the recent code base.

Now, that doesn't mean that such dependent changesets must *never* be
pulled in, especially when they are needed by several backports. But
if dependency changesets substantially multiply the size of a change,
as they do in this case, this should not be done.

I am aware that this does not ease the life of the maintainers, but
that isn't the goal. Stability is.

We need to discuss this issue some more, with a view to producing some
updated guidelines.

> In this case, it would lead to a strdup failure being handled
> differently, depending on where in the code it occurred.
> The alternative would be to use os::strdup directly and avoid
> introducing this function. This was how JDK-8155968 already handled
> this issue.

That sounds like an excellent idea. I'll prepare a new patch.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671