The wrong test was used, checking the sign bit of al rather than whether any bits in the mask 0FF80h are set (value > 007Fh). For values larger than 255 (0FFh) with the mask 80h clear, an incorrect byte would be emitted for the EXTDEF index rather than the expected dual byte encoding. This resulted in truncating these indices to their low 7 bits, with bit 7 zero, discarding any ones in the higher bits 8 to 14.

(The sign bit check would be correct for decoding a possibly dual byte item, or for encoding one that is limited to indices <= 00FFh like the SEGDEF and GRPDEF and LNAMES indices. However, the EXTDEF indices must support use cases with hundreds of extern labels.)

In particular, all the FIXUPP records were still valid as in the wrong byte always was <= 7Fh so the linker didn't become out of sync reading the affected subrecords.

One interesting part is that for every 256th EXTDEF index, the wrong index of zero was emitted. It should be possible to detect this in the linker and have it generate a warning or an error.

Error was observed in the lDDebugX build referencing the occasional wrong patch list entry for the 386 patches. Study of the wllist.obj file revealed that the patch_386_table referenced several entries belonging to the patch_no386_table, with the expected corruption. The used EXTDEF index of 0060h was intended to refer to index 0260h instead, the latter having been identified by being the sixth R5 entry meant to land in the patch_386_table.