What memory-allocating functions should we check for leaks?

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

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".

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

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.