| Format | Assembly Format | Description |
|---|---|---|
| 46 | ldind.i1 |
Indirect load value of type int8 as int32 on the stack. |
| 48 | ldind.i2 |
Indirect load value of type int16 as int32 on the stack. |
| 4A | ldind.i4 |
Indirect load value of type int32 as int32 on the stack. |
| 4C | ldind.i8 |
Indirect load value of type int64 as int64 on the stack. |
| 47 | ldind.u1 |
Indirect load value of type unsigned int8 as int32 on the stack. |
| 49 | ldind.u2 |
Indirect load value of type unsigned int16 as int32 on the stack. |
| 4B | ldind.u4 |
Indirect load value of type unsigned int32 as int32 on the stack. |
| 4E | ldind.r4 |
Indirect load value of type float32 as F on the stack. |
| 4C | ldind.u8 |
Indirect load value of type unsigned int64 as int64 on the stack (alias for ldind.i8). |
| 4F | ldind.r8 |
Indirect load value of type float64 as F on the stack. |
| 4D | ldind.i |
Indirect load value of type native int as native int on the stack |
| 50 | ldind.ref |
Indirect load value of type object ref as O on the stack. |
…, addr → …, value
The ldind.<type> instruction indirectly loads a value from address addr (an unmanaged pointer, native int, or managed pointer, &) onto the stack. The source value is indicated by the instruction suffix. The ldind.ref instruction is a shortcut for a ldobj instruction that specifies the type pointed at by addr, all of the other ldind instructions are shortcuts for a ldobj instruction that specifies the corresponding built-in value class.
If required, values are converted to the representation of the intermediate type (§I.8.7) of the <type> in the instruction when loaded onto the stack (§III.1.1.1).
[Note: that is integer values smaller than 4 bytes, a boolean, or a character converted to 4 bytes by sign or zero-extension as appropriate. Floating-point values are converted to F type. end note]
Correct CIL ensures that the ldind instructions are used in a manner consistent with the type of the pointer.
The address specified by addr shall be to a location with the natural alignment of <type> or a NullReferenceException might occur (but see the unaligned. prefix instruction). (Alignment is discussed in Partition I.) The results of all CIL instructions that return addresses (e.g., ldloca and ldarga) are safely aligned. For data types larger than 1 byte, the byte ordering is dependent on the target CPU. Code that depends on byte ordering might not run on all platforms.
The operation of the ldind instructions can be altered by an immediately preceding volatile. or unaligned. prefix instruction.
[Rationale: Signed and unsigned forms for the small integer types are needed so that the CLI can know whether to sign extend or zero extend. The ldind.u8 and ldind.u4 variants are provided for convenience; ldind.u8 is an alias for ldind.i8; ldind.u4 and ldind.i4 have different opcodes, but their effect is identical. end rationale]
System.NullReferenceException can be thrown if an invalid address is detected.
Correct CIL only uses an ldind instruction in a manner consistent with the type of the pointer. For ldind.ref the type pointer at by addr cannot be a generic parameter.
[Note: A ldobj instruction can be used with generic parameter types. end note]
For ldind.ref addr shall be a managed pointer, T&, T shall be a reference type, and verification tracks the type of the result value as the verification type of T.
For the other instruction variants, addr shall be a managed pointer, T&, and T shall be assignable-to (§I.8.7.3) the <type> in the instruction. Verification tracks the type of the result value as the intermediate type of <type>.