On Thu, Oct 20, 2022 at 08:57:31PM +0200, Rubén Justo wrote:
> "-O2" is what goes public, testing it, directly or indirectly, is useful.
> Another thing is the pay-off..
Sort of. The leak-check build itself is not what goes public, so we have
already diverged from a release build. But yes, if there were cases that
-O2 caught that -O0 did not, that would be of interest.
But are there?
I.e., we already know of false positives with -O2. Are there false
negatives with -O0?
The example you give below goes the other way:
> "False positives" makes me think the leak checker does its best. And the
> compiler. This "-O0 leak" is ignored by both, with "-O2":
>
> void func()
> {
> malloc(1024);
> exit(1);
> }
It is a false negative with -O2. Which again seems to argue for using
-O0.
> UNLEAK(), "-O0" as a /second opinion/ /confirmation/, some attention to the
> false positives,... are things that doesn't sound so bad. Maybe there is a
> better way. Dunno.
I don't know why we'd want to prefer -O2 if we know it produces worse
results, but don't have any cases where it produce better ones (or even
a plausible explanation for why it might). Sure, we could squelch its
false positives with UNLEAK(), but:
- that's per-site work, versus setting -O0 once
- UNLEAK() suppresses false positives, but it also would suppress true
positives (e.g., if the code later changed and somebody introduced a
leak). It seems better to avoid that if possible.
-Peff
