[cfe-dev] [Bug 7772] analyzer reports leaks when data is added to hash table or linked list

[bruce.r.stephens at gmail.com]

Michael Blumenkrantz <mike-n7nqhmouzSVWk0Htik3J/w at public.gmane.org>
writes:

[...]

> With regard to the annotations that you have mentioned, I do not
> believe they will be a full or workable solution to anyone with a
> reasonable sized api who wishes to have accurate results from the
> scanner.  In a case where there are hundreds of function calls such as
> the EFL, it would be extremely frustrating, not to mention annoying,
> to create and maintain such annotations with any degree of accuracy
> That said, I think there would definitely be a place for it in smaller
> applications/libraries, or specialized cases with unusual behavior.

I'm unconvinced.  I'm not familiar with EFL, and I'm not sure what might
be a commonly understood example.

Hmm, what about FILE?  There's a bunch of functions that can take a
FILE* but only a handful that need annotating: fopen() (and similar
functions like fdopen()), fclose(), freopen().  Isn't EFL similar, in
that almost all functions won't need annotation because they'll just use
things passed in to them (without making references, freeing them,
etc.)?

OpenSSL seems to me to be similar to FILE, with just a few wrinkles,
specifically functions like d2i_X509(): that returns an X509* and takes
a parameter X509**px.  If px or *px is NULL then it returns a newly
allocated X509.  In that case if px isn't NULL then *px is set to the
newly allocated X509 (and d2i_X509() returns *px).  If px and *px are
not NULL then it's assumed that *px points to a valid X509 and that's
reused (so there's no new allocation of an X509).  (There's also an
X509_dup(), though I guess malloc() has things like strdup().)

(PKCS#11 has a different pattern it uses for returning vectors of
unknown length which might be a useful test of annotation
expressiveness.  The functions take something like a char* and a
size_t*.

If the char* is non-NULL and the size_t* points to a value that's large
enough for the returned value then the function returns its value into
the char*, setting the size_t* to the length of what's returned.  If the
size_t* is too small then a buffer-too-small error is returned.

If the size_t* points to a value that's zero then the function simply
returns the size of its result.  So a typical invocation when the size
isn't known is to call the function twice: once to get the size, then
you allocate, then you call the function again to get the value.)

[...]