On 1/23/2018 11:40 AM, Pedro Giffuni wrote: > Hi; > > > On 23/01/2018 14:08, Conrad Meyer wrote: >> Hi Pedro, >> >> 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 >>> URL: https://svnweb.freebsd.org/changeset/base/328218 >>> >>> Log: >>> Revert r327828, r327949, r327953, r328016-r328026, r328041: >>> Uses of mallocarray(9). >>> >>> The use of mallocarray(9) has rocketed the required swap to build >>> FreeBSD. >>> This is likely caused by the allocation size attributes which put >>> extra pressure >>> on the compiler. >> 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. The blind use of mallocarray(9) is probably > a mistake also: we shouldn't use it unless there is some real risk of > overflow. > >> (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. > > Pedro. > >
I haven't dug into this to understand it all, but if mallocarray() is causing this sort of compilation problem then isn't the problem the compiler? Why keep a "dangerous" function around and not actually fix it? Is there a bug somewhere to fix the compilation load? -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature