On Mon, 2012-02-27 at 17:40 +0000, Daniele Varrazzo wrote:
On Mon, Feb 27, 2012 at 5:04 PM, David Malcolm
<dmalcolm(a)redhat.com> wrote:
> On Sat, 2012-02-25 at 00:34 +0000, Daniele Varrazzo wrote:
>> Hello,
>>
>> attached there is a patch to implement PySequence_SetItem, which
> Good stuff - thanks!
>
> I noticed that the patch only has the "success" case, which got me
> wondering - what would it take for a call to PySequence_SetItem to fail?
Uhm, sorry, but I still know too little about the plugin internals,
and the patch provided is about cargo-cult of some other function, it
may have been PyList_SetItem. Maybe the same branch is missing there
too - or is there but I failed to identify it.
Oh well; thanks.
>> After cleaning many genuine errors in psycopg, mostly about
unchecked
>> return values, I'm left with several false positives related exactly
>
> I'm very happy to hear that the checker is finding many genuine errors,
> thanks for posting this! Would it be OK if we add a section about this
> to the "Success Stories" section of the documentation? (see
> docs/success.rst in the source tree).
It's definitely being helpful, and I'll be happy to provide you a
success story... but it isn't yet :) It still doesn't compile all the
psycopg source. It takes the patch I've already sent you and I still
have to see how to fix the traceback previously reported. It will be
great to bring it to the end, but it can be helpful only if I can
silence all the false positives, and functions setting exceptions but
not returning a python objects are the bulk of them.
Ooops, sorry, I forgot about
the traceback you mentioned in your other
mail. I'll see if I can reproduce it on my machine.
I can also report that it has found a possible double-dealloc in the
mx.DateTime include file, for which I've already sent a patch to the
author :)
Excellent.
> I started writing an attribute to do this some months ago, but
the patch
> has likely bitrotted; I'll see if I can get it working again...
It would be awesome, thanks ;-)
I fixed it up and committed it as
99d7f63b8f2d9884f059a0801dbf86ad37d49344
This adds:
__attribute__((cpychecker_negative_result_sets_exception))
which can be used to mark function declarations:
/* The checker automatically defines this preprocessor name when
creating the custom attribute: */
#if defined(WITH_CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION_ATTRIBUTE)
#define CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION() \
__attribute__((cpychecker_negative_result_sets_exception))
#else
/* for the case where we're not compiling with the checker */
#define CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION()
#endif
extern int foo(void)
CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION();
Given the above, the checker will know that an exception is raised
whenever a call to `foo` returns a negative value. It will also verify
that foo() actually behaves this way when compiling the implementation
of foo.
Does this give you want you need?
Dave