title: Core Foundation creates a memory leak for every call to CFSTR()
body: <p>I normally use CFSTR() macro to create a CFString object from a standard c string until, after several test and checking better the documentation, I realized that every call to this function creates automatically a memory leak that lives until the program terminates. Visual leak detector still reports the memory as not freed even after the application close.
  Any call to CFRetain, CFRelease does not affect the memory at all.
  Since I make lots of calls, I was wondering if I should use CFStringCreateWithCString where, unlike of CFSTR, the memory is fully freed after calling CFRelease (as also reported from the memory leak detection tool).</p>
  
  <p>Thanks</p>
  
  <p>Update (in reply to comments):
  I'm on Windows and I use the official CoreFoundation library directly from my c++ application. To identify memory leaks I use OpenCfLite because the source code is the same, but allows me to also include the Visual Leak Detector header or, alternatively,  to just use the built-in Visual Studio leak detector. When I close the application I get a full report and I can clearly see the memory address along with its content. I can see from report that the same strings passed to CFSTR(=__CFStringMakeConstantString) are still located at the memory address.
  This does not appear to be a bug or something I've done wrong, but just the normal behavior because as Apple states: "Values returned from CFSTR are not released by CFString and they are guaranteed to be valid until the program terminates."</p>
  
  <p>Sample call:
  CFSTR(<strong>"This string has been created from __CFStringMakeConstantString function"</strong>)</p>
  
  <p><em><strong>---------------This is a dump from Microsoft builtin leak detector:-------------------</em></strong></p>
  
  <p>Detected memory leaks!</p>
  
  <p>Dumping objects -></p>
  
  <p>c:\projects\cftest\cftest\cfbase.c(277) : {61} normal block at 0x00A01648, 96 bytes long.</p>
  
  <p>Data: &lt;        <strong>GThis st</strong>> 00 00 00 00 8C 07 00 00 47 54 68 69 73 20 73 74</p>
  
  <p>Object dump complete.</p>
  
  <p><em><strong>---------------This is a dump from VLD tool:---------------</em></strong></p>
  
  <p>---------- Block 1 at 0x04AD2FE8: 4096 bytes ----------</p>
  
  <p>Call Stack:</p>
  
  <pre><code>0x77D89950 (File and line number not available): ntdll.dll!RtlQueryEnvironmentVariable + 0x241 bytes
  0x77D8D8C9 (File and line number not available): ntdll.dll!LdrResSearchResource + 0xB4D bytes
  0x77D8D78C (File and line number not available): ntdll.dll!LdrResSearchResource + 0xA10 bytes
  0x77D8C4D5 (File and line number not available): ntdll.dll!LdrLoadDll + 0x7B bytes
  0x772A2288 (File and line number not available): KERNELBASE.dll!LoadLibraryExW + 0x1F1 bytes
  0x6FA4DF32 (File and line number not available): clr.dll!GetCLRFunction + 0x895F bytes
  0x6FA4DFAD (File and line number not available): clr.dll!GetCLRFunction + 0x89DA bytes
  0x6FC4ECF0 (File and line number not available): clr.dll!CorLaunchApplication + 0x17DB0 bytes
  0x6F9F421B (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x524C bytes
  0x6F9F42E2 (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x5313 bytes
  0x6F9F3FE4 (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x5015 bytes
  0x6F9AD323 (File and line number not available): clr.dll!LogHelp_NoGuiOnAssert + 0x17457 bytes
  0x6FA57D55 (File and line number not available): clr.dll!GetCLRFunction + 0x12782 bytes
  0x6F9C52D5 (File and line number not available): clr.dll!LogHelp_TerminateOnAssert + 0x16F1D bytes
  0x023D0882 (File and line number not available): (Module name unavailable)!(Function name unavailable)
  0x00370AF3 (File and line number not available): (Module name unavailable)!(Function name unavailable)
  0x6CC8CEA3 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C3A4D34 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C397BBB (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C3979B8 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C3A3B37 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C399828 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C3A285A (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C3A3A60 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C3A26D9 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C399513 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C399491 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x6C8F9B34 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable)
  0x023D0E7B (File and line number not available): (Module name unavailable)!(Function name unavailable)
  0x767262FA (File and line number not available): USER32.dll!gapfnScSendMessage + 0x332 bytes
  0x76726D3A (File and line number not available): USER32.dll!GetThreadDesktop + 0xD7 bytes
  0x76726DE8 (File and line number not available): USER32.dll!GetThreadDesktop + 0x185 bytes
  </code></pre>
  
  <p>........ <strong>GThis.st</strong></p>
  
  <p>72 69 6E 67    20 68 61 73    20 62 65 65    6E 20 63 72     <strong>ring.has .been.cr</strong></p>
  
  <p>65 61 74 65    64 20 66 72    6F 6D 20 5F    5F 43 46 53     <strong>eated.fr om.__CFS</strong></p>
  
  <p>74 72 69 6E    67 4D 61 6B    65 43 6F 6E    73 74 61 6E     <strong>tringMak eConstan</strong></p>
  
  <p>74 53 74 72    69 6E 67 20    66 75 6E 63    74 69 6F 6E     <strong>tString. function</strong></p>
  
  <p>00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00     ........ ........</p>
  
  <p>Now, I can easily avoid all of the above issues by replacing any call to CFSTR with CFStringCreateWithCString where I'm sure that there are no memory leaks (at least as long as I remember to call CFRelease), but I would like to know why lots of code samples show an heavy use of CFSTR if every call to this function stores the string in memory which is possible to free only when the program terminates.</p>
  
  <p>Thanks</p>