Databases
StackOverflow2013
Postsdbo
POAccessing static member through invalid pointer: guaranteed to "work"?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POAccessing static member through invalid pointer: guaranteed to "work"?
    primarykey
    data
    text
    <p><strong>Setup</strong></p> <p>Given this user-defined type:</p> <pre><code>struct T { static int x; int y; T() : y(38); }; </code></pre> <p>and the requisite definition placed somewhere useful:</p> <pre><code>int T::x = 42; </code></pre> <p>the following is the canonical way to stream the <code>int</code>'s value to <em>stdout</em>:</p> <pre><code>std::cout &lt;&lt; T::x; </code></pre> <p><strong>Control</strong></p> <p>Meanwhile, the following is (of course) invalid due to an instance of <code>T</code> not existing:</p> <pre><code>T* ptr = NULL; // same if left uninitialised std::cout &lt;&lt; ptr-&gt;y; </code></pre> <p><strong>Question</strong></p> <p>Now consider the horrid and evil and bad following code:</p> <pre><code>T* ptr = NULL; std::cout &lt;&lt; ptr-&gt;x; // remember, x is static </code></pre> <p>Dereferencing <code>ptr</code> is invalid, as stated above. Even though no physical memory dereference takes place here, I <em>believe</em> that it still counts as one, making the above code UB. Or... does it?</p> <p>14882:2003 5.2.5/3 states explicitly that <code>a-&gt;b</code> is converted to <code>(*(a)).b</code>, and that:</p> <blockquote> <p>The postfix expression before the dot or arrow is evaluated; This evaluation happens even if the result is unnecessary to determine the value of the entire postfix expression, for example if the id-expression denotes a static member.</p> </blockquote> <p>But it's not clear whether "evaluation" here involves an actual dereference. In fact neither 14882:2003 nor n3035 seem to explicitly say either way whether the pointer-expression has to evaluate to a pointer to a valid instance when dealing with static members.</p> <p>My question is, just how invalid is this? Is it really specifically prohibited by the standard (even though there's no physical dereference), or is it just a quirk of the language that we can probably get away with? And even if it is prohibited, to what extent might we expect GCC/MSVC/Clang to treat it safely anyway?</p> <p>My g++ 4.4 appeared to produce code that never attempts to push the [invalid] <code>this</code> pointer onto the stack, with optimisations turned off.</p> <p><strong>BTW</strong> If <code>T</code> were polymorphic then that would not affect this, as static members cannot be virtual.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USLightness Races in Orbit
    1. USLightness Races in Orbit
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POAccessing static member through invalid pointer: guaranteed to "work"?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POAccessing static member through invalid pointer: guaranteed to "work"?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POAccessing static member through invalid pointer: guaranteed to "work"?
      1. USLightness Races in Orbit
      1. VTFavorite
    1. COThere's some related discussion concerning this at [When does invoking a member function on a null instance result in undefined behavior?](http://stackoverflow.com/questions/2474018/when-does-invoking-a-member-function-on-a-null-instance-result-in-undefined-behav) (Your question is about static data members; static member functions were discussed in the other question). The consensus was that it _should_ be allowable but is not; there's a closed DR that would make it allowable but that DR relies on the resolution to a still-open DR (whether that consensus was correct is open for debate :-D)
      singulars
      1. POAccessing static member through invalid pointer: guaranteed to "work"?
      1. USJames McNellis
    2. COThe issue is that the closed DR (CWG defect 315) says "`*p` is not an error when `p` is null unless the lvalue is converted to an rvalue." However, this relies on the concept of an "empty lvalue," which is part of the proposed resolution to the still-open [CWG Defect 232](http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232).
      singulars
      1. POAccessing static member through invalid pointer: guaranteed to "work"?
      1. USJames McNellis
    3. CO@James: So we're saying that it's just another inconclusive quirk of the delicious mess that is C++? :)
      singulars
      1. POAccessing static member through invalid pointer: guaranteed to "work"?
      1. USLightness Races in Orbit
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload