title: In assembly, how to handle Windows API with a return value that's documented as less than native register width?
body: <p>For many years, <a href="https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-ntohs" rel="nofollow noreferrer">ntohs</a> (32-bit version) had a return value
  that was zero extended into the high 16 bits (word). However, after a recent update of Windows 10, it sometimes returns garbage in the upper word.</p>
  <p>For example, passing argument 0xF00D to</p>
  <pre><code>call        ntohs
  </code></pre>
  <p>the return values are</p>
  <ul>
  <li>EAX = 00F00DF0 (32-bit code)</li>
  <li>RAX = 0000000000000DF0 (64-bit code)</li>
  </ul>
  <p>The fix in MASM code is to zero extend the return register using <a href="https://www.felixcloutier.com/x86/movzx" rel="nofollow noreferrer">movzx</a> (identical to MSVC)</p>
  <pre><code>call        ntohs
  movzx       eax, ax
  </code></pre>
  <p><strong>Question</strong></p>
  <p>Is it correct that any Windows API with a return value that's documented as less than native register width, there's no guarantee of the upper bits being zeroed out i.e., the return value in RAX = 0000000000000DF0 (64-bit) was most likely coincidental?</p>