title: Const type qualifier when doing pointer things
body: <p>Let's say I have a local variable <code>int var;</code> that I use for retrieving some value by calling another function, like so: <code>func(..., &amp;var);</code>.</p>
  
  <p>Then I check the retrieved value for certain things and act accordingly. After variable <code>var</code> has received its value, <code>var</code> will never change again from that point on.
  Would it then make sense to define <code>var</code> as <em>const</em>? (<code>int const var;</code>).</p>
  
  <p>I'm not sure if that's the correct way to use the <em>const</em> keyword because the initial value of <code>var</code> is something left over from the stack and changes when <code>func</code> is called: <code>func(..., &amp;var);</code>. So, in some way that contradicts the <em>const</em> type qualifier.</p>
  
  <p>The reason that I'm unsure about this is because the effect (or result) of defining variable <code>var</code> as <em>const</em> (<code>int const var;</code>), is the desired behavior for the code that follows within the scope of <code>var</code>.
  I.e, it should not be allowed to change the value of <code>var</code> directly with the use of the assignment operator even though the value of <code>var</code> was just changed by some pointer within the <code>func</code> function.</p>
  
  <p><strong>Example</strong></p>
  
  <pre><code>int foo(void)
  {
      int const var;
  
      if (!func(..., &amp;var))
          return 0;
  
      if (var == x)
          // do some stuff
      else if (var == y)
          // do some other stuff
      else
          // nope
  
      return var * x + y;
  }
  </code></pre>
  
  <p>I wonder if in terms of correctness the <em>const</em> type qualifier for defining <code>var</code> still applies to that situation. </p>
  
  <hr>
  
  <blockquote>
    <p>Regarding correctness, at least with gcc you can pass your const var
    to the modifying function, but it generates a warning. I would neither
    recommend nor do it. It does not help rather than confuse the reader.</p>
  </blockquote>
  
  <p>It seems that I have stumbled down the wrong path by misinterpreting the resulting behavior of MSVC. While having <code>/Wall</code> enabled, the only warning that MSVC produced was <code>const object should be initialized</code>. Which I didn't think much of because by just initializing <code>var</code>, to see what would happen, the result was a clean compilation.</p>
  
  <p>But I think I have some idea of what is happening, at least. If you have a <em>const</em> data type, the compiler thinks that you should not write to something that is read-only, even when doing so with the use of pointers. So, the only time that it makes sense for the compiler to see the address of a <em>const</em> variable being passed to a function, is when that variable contains anything but a garbage value. Hence the initialization warning.</p>
  
  <blockquote>
    <p>If var is used in equality comparisons like in your example, making it
    const could avoid the if (var = ...) vs. if (var == ...) typo because
    the compiler would catch that.</p>
  </blockquote>
  
  <p>In regard to using <em>const</em> or not when trying to catch this error; I think it has more to do with having the assurance of the compiler spitting something out based on the ruling defined within the standard, than it has with the compiler producing or not producing a warning if <em>const</em> is omitted from the definition of <code>var</code>.</p>