title: Poisoning certain API functions (not being maintainer)
body: <p>Related to e.g.:
  <a href="https://stackoverflow.com/questions/34118209/how-to-poison-an-identifier-in-vc">How to poison an identifier in VC++?</a><br />
  <a href="https://stackoverflow.com/questions/33964621/what-does-it-mean-to-poison-a-function-in-c">What does it mean to &quot;poison a function&quot; in C++?</a></p>
  <p>Is there a way to &quot;properly&quot; poison some functions whose declarations (or implementations) are not under my control?</p>
  <p>Specifically, I'm trying to prevent accidential use of certain Windows API functions which may result in surprise results, such as e.g. <code>CreateFileA</code> (where use of the T macro hides the fact that you mix ANSI and Unicode) or <code>SetWindowLong</code> (which will cause your program to fail silently, without error, and without a chance of knowing what went wrong on a 64-bit system).</p>
  <p>My definition of poisoning &quot;properly&quot; is that <strong>attempting to call</strong> the function breaks the build with a readable error (bonus points if the error occurs at the correct location in the source code).<br />
  Preferrably, this should be portable, and at the very least it must work with both GCC and clang.</p>
  <p>What I've tried / looked at so far:</p>
  <h3>preprocessor</h3>
  <p>The simplest, immediately obvious solution would be to exploit the preprocessor:</p>
  <pre><code>#define CreateFileA __poison_ANSI_CreateFileA
  </code></pre>
  <p>This works very well for that one particular function as well as a couple of others, working exactly as intended, with a precise error that hints to the problem and points to the correct location in the source:</p>
  <pre><code>error: no matching function for call to '__poison_ANSI_CreateFileA'
  note: expanded from macro 'CreateFile'
  note: expanded from ... (precise location in source)
  </code></pre>
  <p>For different functions, one needs to have a unique name for each to avoid conflicting definition errors, which is tedious but easily done. So far so good, except it <em>does not</em> work for functions where the MinGW-w64 headers themselves tamper names using variadic macros, such as for example <code>CreateWindow</code> or <code>SetWindowLong</code>. No matter what, these compile just fine, poisoned or not.</p>
  <h3>pragma</h3>
  <p><code>#pragma GCC poison</code>, which clang happens to understand as well (and also features its own version), looks and sounds like it should do exactly what I want, and in the most idiomatic way possible. Alas, it does not work. Or rather, it works <em>too well</em>.<br />
  Functions poisoned with the pragma directive already trigger an error when the poisoned name appears in a declaration, which means... <em>every time</em>, in every build that includes the header at all. That's not very helpful for writing a program!</p>
  <h3>attributes</h3>
  <p>These have the immense disadvantage that you must copy exactly the type definition lest you get &quot;ambiguous function call&quot; errors on legitimate calls on the one hand side. On the other hand side, they don't work. clang complains about <code>__attribute__((__error__))</code> but ignores <code>gnu::__error__</code> or <code>gnu::error</code> as well as <code>gnu::deprecated</code>. Further, the standard <code>[[deprecated]]</code> is all nice and well, but seems to do exactly nothing (compiles fine, not even a warning?!).</p>
  <p>Is there anything I can do?</p>