On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni <p...@freebsd.org> wrote: > On 23/01/2018 14:08, Conrad Meyer wrote: >> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni <p...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
