Stephen Gildea <[email protected]> wrote: > I agree with Robert that we don't care if a program allocates a lot of > memory that it doesn't free before exiting. And I'm not proposing to > change that, which would, as Robert points out, make the code more > complicated for no performance gain.
> What I am proposing is to re-arrange the code slightly to show ASan
> that we don't care. That would 1) make it easier to use ASan and 2)
> make it easier to find leaks we do care about.
I've not been a fan of ASan over time.
Probably it's gotten better.
More often than not it's just produced annoyance for me.
Warnings that show up only on one platform with one version of a compiler,
and seem impossible to track down.
But, if you think it's worthwhile doing this with ASan, I do not object.
(There may be better tools to get the information out that would also shut up
ASan)
I think that it's particularly worth it in anything that's in the library,
and I think you are trying to get those details to stand out by getting rid
of the cruft.
I think that the libraries could get used more in the future if someone
manages to finally teach some IMAP server about MH folders. I wish I had
time to hack this... I'd like to FFI (RUST) wrap libnmh.
> And yes, there are leaks we care about. If a program were to leak
> memory in proportion to the amount of data it processes, then the
> resulting memory growth would limit the size of the folder the program
> could operate on.
Yes, particularly if it could have been a static!
signature.asc
Description: PGP signature
