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

[Conrad Meyer]

On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh <imp at 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.

Best,
Conrad