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 Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni <pfg at freebsd.org> wrote:
> On 23/01/2018 14:08, Conrad Meyer wrote:
>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni <pfg at freebsd.org> wrote:
>>>
>>> Author: pfg
>>> Date: Sun Jan 21 15:42:36 2018
>>> New Revision: 328218
>>
>> I'm confused about this change.  Wouldn't it be better to remove the
>> annotation/attributes from mallocarray() than to remove the protection
>> against overflow?
>
>
> Not in my opinion: it would be better to detect such overflows at compile
> time (or through a static analyzer) than to have late notification though
> panics.

Sure, it would be better, but some situations are only detected at
runtime -- hence mallocarray.  And occasional use of the annotations
on systems with plenty of RAM would keep the source tree free of
compiler-detectable overflows, which I suspect are incredibly
uncommon.

> The blind use of mallocarray(9) is probably a mistake also: we
> shouldn't use it unless there is some real risk of overflow.

I'm not sure I follow that.

>>    (If the compiler is fixed in the future to not use
>> excessive memory with these attributes, they can be conditionalized on
>> compiler version, of course.)
>
> All in all, the compiler is not provably wrong: it's just using more swap
> space, which is rather inconvenient for small platforms but not necessarily
> wrong.

Seems wrong if it's a noticeable amount.  Maybe we could flip the
annotations on or off with a low-ram build knob or something like
that.

Best,
Conrad