[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cf8da58-de8b-e171-5a40-2b10983d447@linux-m68k.org>
Date: Thu, 21 Oct 2021 09:50:26 +1100 (AEDT)
From: Finn Thain <fthain@...ux-m68k.org>
To: James Bottomley <jejb@...ux.ibm.com>
cc: Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>,
kashyap.desai@...adcom.com, sumit.saxena@...adcom.com,
shivasharan.srikanteshwara@...adcom.com,
martin.petersen@...cle.com, megaraidlinux.pdl@...adcom.com,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox()
allocation failure
On Wed, 20 Oct 2021, James Bottomley wrote:
> >
> > ... and arguably they would be correct.
>
> Well, yes ... that's why I don't want one "fix" that generates a
> cascading sequence of further "fixes".
>
OTOH, if you don't "fix" it, it generates a cascading sequence of
copy-and-paste antipatterns in new code, and poor training data for those
of us reading old code.
Anyway, I agree that the churn would be too risky. But it sure would be
nice if automatic tools were able to perform a program transformation of
this kind at the source level, being that the compiler will surely do it
anyway at a lower level.
There's a lot to be said for source code that reflects the compiler's
understanding of the logic, rather than the human's.
Powered by blists - more mailing lists