[cfe-dev] What memory-allocating functions should we check forleaks?

[Alexander Riccio via cfe-dev]

> Perhaps it would make sense to look at the Win32 headers for anything annotated with _Ret_notnull_, _Ret_maybenull_, _Ret_null_, or _Ret_valid_? IIRC, those are for functions that return allocated storage.

Ahh, that's actually really good idea! I'll also check for _Post_writable_byte_size_ (on malloc) which reminds me that I should add VirtualAlloc and friends to the list.

It'd be nice if we had a more generic mechanism for this.

Side note: The VirtualAlloc family of memory APIs are super hard to correctly check. It'd be unreasonably hard for anybody to write a checker for them without parsing the carefully written SAL in the headers. IIRC, even projects that aggressively test & audit their code don't get the virtual memory API usage correct without /analyze.




sent from my (stupid) windows phone

-----Original Message-----
From: "Aaron Ballman" <aaron at aaronballman.com>
Sent: ‎3/‎8/‎2016 1:40 PM
To: "<Alexander G. Riccio>" <test35965 at gmail.com>
Cc: "cfe-dev" <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] What memory-allocating functions should we check forleaks?

On Fri, Mar 4, 2016 at 5:17 PM, <Alexander G. Riccio> via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> As a continuation of D17688 (add MSVC variants of strdup to leak checks),
> I'm going to add a bunch of other Microsoft functions to the static
> analyzer. I'm also going to add tempnam, a cstdlib function that returns a
> pointer to memory that must be manually freed.
>
> What other functions should I add?
>
>
> Currently, I'm going to add:
>
> _free_dbg
> _malloc_dbg
> _realloc_dbg
> _recalloc_dbg
> _calloc_dbg
> _strdup_dbg
> _wcsdup_dbg
> _mbsdup
> _mbsdup_dbg
> tempnam
> _tempnam
> _tempnam_dbg
> _wtempnam
> _wtempnam_dbg

These seem like a good start. The other function you list below would
also be nice to provide analysis for eventually. I don't see anything
missing from your list that immediately jumps out to me. Perhaps it
would make sense to look at the Win32 headers for anything annotated
with _Ret_notnull_, _Ret_maybenull_, _Ret_null_, or _Ret_valid_? IIRC,
those are for functions that return allocated storage.

~Aaron

> A bunch of other functions that I'd like to add, but are non-trivial to add,
> so I'll hold off on them for now:
>
> Aligned functions (I think that you're not supposed to mix them with their
> non-aligned variants)
>
> _aligned_free
> _aligned_free_dbg
> _aligned_malloc
> _aligned_malloc_dbg
> _aligned_msize
> _aligned_msize_dbg
> _aligned_offset_malloc
> _aligned_offset_malloc_dbg
> _aligned_offset_realloc
> _aligned_offset_realloc_dbg
> _aligned_offset_recalloc
> _aligned_offset_recalloc_dbg
> _aligned_realloc
> _aligned_realloc_dbg
> _aligned_recalloc
> _aligned_recalloc_dbg
>
> Functions that should be freed with a function other than free:
>
> _free_locale
>
> _create_locale
> _wcreate_locale
>
> Functions that only return dynamically allocated memory in certain
> conditions:
>
> getcwd
> _getcwd
> _getcwd_dbg
> _wgetcwd
> _wgetcwd_dbg
> _getdcwd
> _getdcwd_dbg
> _wgetdcwd
> _wgetdcwd_dbg
> realpath
> _fullpath
> _fullpath_dbg
> _wfullpath
> _wfullpath_dbg
>
> Functions that return dynamically allocated memory via an "_Out_"
> parameter*:
>
> _dupenv_s
> _dupenv_s_dbg
> _wdupenv_s
> _wdupenv_s_dbg
>
> Functions which may allocate stack or heap:
>
> _malloca (must be freed with _freea)
>
> Functions that return non-freeable memory, if passed NULL, but look like
> users should free them. These two are very weird, and therefore it might be
> very useful to check:
>
> tmpnam
> _wtmpnam
>
>
> *for the SAL obsessed (like me) it's actually
> "_Outptr_result_buffer_maybenull_(*_BufferCount)
> _Outptr_result_maybenull_z_".
>
> Sincerely,
> Alexander Riccio
> --
> "Change the world or go home."
> about.me/ariccio
>
> If left to my own devices, I will build more.
> ⁂
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160308/5dd14502/attachment.html>