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

[Andrew Haley]

On 26/05/2020 22:25, Andrew Hughes wrote:
>
> Completely agree. My aim was to balance what aph said, rather than
> suggest that we go to the other extreme.

> I also think we need to be very aware of the growing expertise
> needed to maintain 8u. Thank you for expanding on this in more
> detail.

I'm very grateful for Andrew Dinn's reply. In particular I was
startled by the idea that backporting dependent changes might in some
way deskill the process, such that the knowledge and experience needed
for someone to work on backports is reduced.

> When I look a a proposed backport, I like to see that potential
> dependencies have been considered, even if it is then decided to
> work around them.

Fair enough, consider them, but I will repeat a crucial part of what
Andrew Dinn wrote:

>> Downstream fixes should normally only presume the presence of such
>> a dependency if there is a compelling need to have that dependency
>> /in its own right/. If not then the default assumption has to be
>> that a downstream fix should be sought without relying on that
>> upstream dependency.

A direct consequence of this is that backporting a dependency has to
be justified in a strong way: it should be needed.

> My experience of working on backports for 6u & 7u over the last
> decade or so suggests that no situation is ever the same as
> another. In one case, you may need to completely rewrite the fix
> (common with HotSpot, where there are often significant refactorings
> and major reworkings). In another, it may make sense to backport a
> dependent change, because it's low risk and very likely to be a
> dependency of other future changes (common with testing
> infrastructure)

It is not appropriate to import dependent patches simply because they
might be needed by future patches or in order to reduce the divergence
between 8u and trunk. I'm happy enough with this for test code, but
not for changes to the runtime code.

I'm aware that this constitutes a change to the way that maintenance of
JDK updates has been done for some time. However, as JDK 8u matures
it is a necessary change.

-- 
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