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

Andrew Hughes gnu.andrew at redhat.com
Thu May 28 13:36:13 UTC 2020


On 28/05/2020 09:31, Andrew Dinn wrote:
> On 27/05/2020 19:06, Andrew Hughes wrote:
> 
>> I'm struggling to see where we disagree here.
> I think we are mostly disagreeing over emphasis -- which always risks
> straying into the arena of angels dancing on pinheads (or, to add a dash
> of Bertrand Russell to Rumsfeld's epistemological categories, unknowable
> unknowns -- which in epistemic terms implies a very pink-about-the-gills
> type of fish).
> 
> Rather than enter that arena might I suggest we restate our agreement
> over, and *emphasize* for future reference, this one key maxim regarding
> backporting of dependent upstream fixes:
> 
>   Downstream fixes should normally only presume the presence of a
> dependent upstream fix 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.
> 
> That's not absolute because we are all reasonable people and need to
> allow for and accept well reasoned arguments. However, it does mean
> pulling in extra patches needs to be provided with such good reasons (in
> an RFC thread).
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

No argument from me on that.

My concern here has always been the stage prior to that; ensuring that
the required research into the original context and any dependent fixes
has taken place. Without knowing why the code is different, it is
possible to miss implicit assumptions in the patch being backported.

As you said, the bug and patch need to be considered in the context of
8u. To do that, you first need to understand the original context in
which the fix was made.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222



More information about the jdk8u-dev mailing list