title: Creating and assigning a value to lvalue when the rvalue depends on the lvalue
body: <p>I was a bit surprised to see this code not throw a compile error, and was a bit curious as to why it works.</p>
  
  <p><code>packet</code> is an object that contains a byte-array, and I read it with these custom methods. The function will read the bytes from <code>location</code> up to <code>length</code>.</p>
  
  <p>Usually, I just write:</p>
  
  <pre><code>uint8_t byte;
  byte = *(uint8_t*) [packet getBytes:&amp;byte startingFrom:&amp;byteLocation length:sizeof(byte)];
  </code></pre>
  
  <p>but was surprise to see that this following line also seems to be valid.</p>
  
  <pre><code>uint8_t byte = *(uint8_t*) [packet getBytes:&amp;byte startingFrom:&amp;byteLocation length:sizeof(byte)];
  </code></pre>
  
  <p>Can anyone illuminate me as to how the right hand side of this statement can depend on the left hand side to have been created? Are there any potential pitfalls that I should be worried about even though I am not getting any compile time errors (for iOS 8 application)? Thanks</p>
  
  <p><strong>Edit:</strong></p>
  
  <p>Without getting into the specifics too much of why this function is written the way it is (which is mostly just for reducing lines of code on the page), this function does just copy a value into <code>byte</code> from an array of bytes, and also returns it as a value. It also auto advances the byteLocation by the length parameter, so you can just call these lines one after another to parse a byte data array into all it's value components.</p>
  
  <p>The packet object contains this method:</p>
  
  <pre><code>- (nonnull void*)getBytes:(nonnull void*)buffer startingFrom:(nonnull NSUInteger*)location length:(NSUInteger)length {
  NSRange range = NSMakeRange(*location, length);
  [self.data getBytes:buffer range:range];   // self.data is just an NSData*
  
  *location = range.location+range.length;
  
  return buffer;
  }
  </code></pre>
  
  <p>That return value is just a convenience to trigger some KVO notifications when used in other cases, not this particular case.</p>
  
  <p>Also, yes while this example is using Objective-C to describe the question, you could easily write these functions in C / C++, which is why they were originally tagged C/C++ and see similar behavior. I figured someone who understands more about how these statements get broken down to the assembly level might enlighten me. As stated in the comments, I suspect that the lvalue here is getting created first, the rvalue is then evaluated, and finally the rvalue is assigned to the lvalue storage area, but would like to know if that theory is correct or there is another explanation.</p>