Memory Array Mapped Address Ending Address math is awkward

[jrgerber]

pr_attr("Ending Address", "0x%08X%03X",
    DWORD(data + 0x08) >> 2,
    ((DWORD(data + 0x08) & 0x3) << 10) + 0x3FF);

The above math results in an awkward looking value on an Azure VM:

Handle 0x0052, DMI type 19, 15 bytes
Memory Array Mapped Address
        Starting Address: 0x00000000000
        Ending Address: 0x000400003FF
        Range Size: 1 GB
        Physical Array Handle: 0x0051
        Partition Width: 1

Handle 0x0053, DMI type 19, 15 bytes
Memory Array Mapped Address
        Starting Address: 0x00100000000
        Ending Address: 0x001400003FF
        Range Size: 1 GB
        Physical Array Handle: 0x0051
        Partition Width: 1

Clearly the VM is off by a byte. No memory range is going to be from 0x0 to 0x00100000 kB. The range would be 0x0 to 0x000FFFFF.

The above math attempts to convert an ending address in kB to an ending address in bytes. After a multiply by 1024 the 0x3FF is an attempt to fill the bits to the right. In a normal case we would have:
0x000FFFFF kB becomes 3FFFFC00 bytes. Add 0x3FF and you get 0x3FFFFFFF.

A solution that would avoid the odd look (granted, yes this would never have happened if the VM calculated correctly) and more to the intent would be to detect if the last bit is a 1 (an odd number) and IIF, then add the 0x3FF.