http://llvm.org/bugs/show_bug.cgi?id=22551
Steven Stewart-Gallus <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #6 from Steven Stewart-Gallus <[email protected]> --- > The report is not actionable. Please provide a reproducer and then > reopen. I don't need a reproducer. All one needs to do is use the -fsanitize-address and the leak checker is enabled. Also, I find it really annoying when people rush to close an issue as invalid instead of having a bit of patience. > Also, as Alexey says, you can always use ASAN_OPTIONS=detect_leaks=0 I can add workarounds for lots of bad software. But eventually it becomes easier to stop using such software. > Sorry, I don't think the example you provided look convincing. The > code has a bug: apparently there is no way to use > linted_error_string() "correctly" (without leaking the memory), and > it can cause real problems if one starts to call this function > frequently. I have a "void linted_error_string_free(char const *str);" function that is usable if it is required. It if it is not needed though I don't use it because I don't need to. > There is no way to disable leak detection in a final executable at > compile time. This seems odd to me but if this is the real reason why leak checking was enabled by default then that is sad. Bad design of implementation details should not leak out into interfaces. Still, what has done has been done and I am fine if fixing this would take a while because internal implementation details have to be rearranged and fixed up. Thank you, Steven Stewart-Gallus -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
