Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jan 2018 11:04:08 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        cem@freebsd.org, Warner Losh <imp@bsdimp.com>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev/...
Message-ID:  <1516817048.42536.182.camel@freebsd.org>
In-Reply-To: <CAG6CVpWv32FjZggRCM3JNWCsMDOSXbVzQfP-dh73fei6Hqr5Mw@mail.gmail.com>
References:  <201801211542.w0LFgbsp005980@repo.freebsd.org> <CAG6CVpXxuFyHS11rF=NF6bSSkC2=xnDh=WnbK-aWp4sOomrZ7w@mail.gmail.com> <51ff8aef-5660-7857-e4d5-12cdc77bc071@FreeBSD.org> <20180124182548.X1063@besplex.bde.org> <CANCZdfpL7t_J6xXi8w%2BwtxE%2B4x8EA0AzqzQKno=dUKaJ_NXFrw@mail.gmail.com> <CAG6CVpWv32FjZggRCM3JNWCsMDOSXbVzQfP-dh73fei6Hqr5Mw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2018-01-24 at 09:34 -0800, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh <imp@bsdimp.com> wrote:
> > 
> > I agree completely. It doesn't do what you think it is doing, for all the
> > reasons that Bruce outlines. We thought it was a bad idea when it came up 2
> > years ago and nothing has really changed.
> I disagree.  I'm not sure what you mean by "it doesn't do what you
> think it is doing."  Do you think the manual page is unclear or needs
> more detail?  It seems clear to me, but it also does what I think it
> does.
> 
> Your description of two years ago is inaccurate — you thought it was a
> bad idea, and were the most vocal on the mailing list about it, but
> that viewpoint was not universally shared.  In a pure headcount vote I
> think you were even outvoted, but as the initiative was headed by a
> non-committer, it sputtered out.
> 
> If Bruce has made some important point or illumination, please
> highlight it.  It's buried in the mostly nonsense wall of text
> boilerplate he usually includes.
> 
> mallocarray serves an important function — a last ditch seatbelt
> against overflowing allocations that can trivially replace existing
> naive malloc calls containing multiplication.  Trivial heap corruption
> is replaced with DoS — a strict improvement.  That is all it does.
> 

The fact that you trivially dismiss the detailed explanation of why the
function isn't useful without even reading it means that the only real
option is to also trivially dismiss anything you have to say on the
subject.

I agree that Bruce's long missives are often full of non-actionable
information, and I usually don't bother to read them unless I intend to
respond on the subject being discussed.  But when the arguments
presented in them are on-point, however tediously expressed, then you
litterally CANNOT dismiss them and expect anyone to take you seriously.

And for what it's worth, I also come down on the side of removing and
not using mallocarray(), but I freely admit it's more of a gut-reaction 
thing for me than something I arrived at by careful analysis (so my
opinion is also pretty easily dismissable -- after 40 years at this, I
tend to trust my gut, but I don't expect anyone else to).

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1516817048.42536.182.camel>