[cfe-dev] Silencing an analyzer warning

Jeffrey Yasskin jyasskin at google.com
Thu Apr 29 10:02:34 PDT 2010

Wouldn't it make more sense to add annotations to the analyzer so that
users can annotate that curl_easy_setopt steals a reference from its
third argument or that the caller promises to release that argument at
the same time as they release 'handle'? Then the analyzer would have
enough information to complain when a caller _forgot_ to CFRetain that
argument, instead of just hiding both kinds of mistakes.

Obviously an escape hatch is useful too, for cases that don't have
analyzer support yet, but it shouldn't be the long-term fix.


On Thu, Apr 29, 2010 at 9:21 AM, Ted Kremenek <kremenek at apple.com> wrote:
> There is currently no good way to silence warnings using attributes or pragmas, but you should be able to get around the issue with a wrapper function:
>  static inline CFTypeRef CFRetainForCurl(CFTypeRef obj) { CFRetain(obj);  return obj; }
>  ...
>  curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetainForCurl(result));
> This isn't a permanent solution; it's essentially relying on a deficiency in the analyzer when it comes to wrapper functions (and so eventually a leak will be reported for this case as well).  However, the plan is to eventually add pragma support (or something like that) to silence specific analyzer warnings.
> On Apr 29, 2010, at 5:08 AM, Joe Ranieri wrote:
>> CURL *handle = curl_easy_init();
>> RequestInfo *result = [[[RequestInfo alloc] init] autorelease];
>> // Keep a pointer to this object around so that curl can give it back to
>> us in callbacks
>> curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetain(result)));
>> The static analyzer tells us that result is leaked (which, without it
>> knowing about curl, it does look like). However, it's not actually being
>> leaked and gets cleaned up later when we clean up the CURL handle. Is
>> there any way to silence this analyzer warning? We'd like to get our
>> project analyzer-warning free and require no warnings before committing
>> things.
>> -- Joe Ranieri
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list