Created attachment 392408 [details] Build log .gz * smartcard/scard/memlog.h:50:26: warning: attempt to free a non-heap object ‘temp3’ [-Wfree-nonheap-object] * smartcard/scard/memlog.h:50:26: warning: attempt to free a non-heap object ‘temp3’ [-Wfree-nonheap-object] * smartcard/scard/memlog.h:50:26: warning: attempt to free a non-heap object ‘temp4’ [-Wfree-nonheap-object] * smartcard/scard/memlog.h:50:26: warning: attempt to free a non-heap object ‘temp4’ [-Wfree-nonheap-object] etc.
* Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://pyscard.sourceforge.net/ http://pypi.python.org/pypi/pyscard ?
Sure, if you don't care about the package. pyscard + pssi suggested for treecleaning.
(In reply to Michał Górny from comment #2) > Sure, if you don't care about the package. pyscard + pssi suggested for > treecleaning. The # of packages that are classified as "crypto" is huge. Mostly added per developers that maintained by their own, then given up, or someone that actually used a package and then left. These cases are maintained by me only when there is a report with a solution or a solution is trivial, as I cannot actually test all, not to mention that I do not use these. I am fine with tree cleaning this one, or leave it per upstream low quality state...
@mgorny, is this problem major enough for treecleaning the package? (to try to explain it a bit more in lastrites message and prevent people from blaming on me trying to kill "working" packages ;)) @alonbl, feel free to CC us (treecleaners) on any bug assigned to crypto that you consider could deserve the removal of the package and we will take care of the rest of the process :)
(In reply to Pacho Ramos from comment #4) > @mgorny, is this problem major enough for treecleaning the package? (to try > to explain it a bit more in lastrites message and prevent people from > blaming on me trying to kill "working" packages ;)) I do not think it is major enough.
we checked this, the code is swig generated, and there is a conditional to avoid releasing non heap addresses, this is false positive.
Isn't there anything portage could use to detect this kind of false positives?
(In reply to Pacho Ramos from comment #7) > Isn't there anything portage could use to detect this kind of false > positives? hmmm... I do not know about portage detection... but the code looks like: { char buffer[100]; variable var = &buffer; var->allocated = false; <snip> if (var->allocated) { free(var); } } as this is generated code (swig), I guess they wanted to avoid extra logic and apply same epilogue to all cases.
If something indeed cares enough to find out that this never evaluates to true, it's more likely to throw another warning about condition that always evaluates to true :).
Sorry, I meant false :).
