crufty memcmp on 386

[Col. G. L. Sicherman]

In <1990Nov13.182133.27748 at loft386.uucp>, dpi at loft386.uucp writes:
> 
> I can't make the original fail.  Could you provide a short code segment
> that will display the claimed behavior?  If you can make AT&T's fail,
> I would like to know if mine fails also.

Sure.  Here are my test program and what came out of it:

REPEAT BY:
	Compile this with cc and run it.

main()
{
	long a[4];
	int i, j;
	int memcmp();

	a[0] = 0x10000000;
	a[1] = 0x50000000;
	a[2] = 0x90000000;
	a[3] = 0xd0000000;

	for (i=0; i<4; i++) for (j=0; j<4; j++)
	if (i!=j)
	printf("memcmp(%lx,%lx,4) is %lx\n", a[i], a[j], memcmp(a+i,a+j, 4));
}

THE DAMNING EVIDENCE:

memcmp(10000000,50000000,4) is ffff8720
memcmp(10000000,90000000,4) is ffff8320
memcmp(10000000,d0000000,4) is 320
memcmp(50000000,10000000,4) is 224
memcmp(50000000,90000000,4) is ffff8724
memcmp(50000000,d0000000,4) is ffff8324
memcmp(90000000,10000000,4) is ffff8228
memcmp(90000000,50000000,4) is 228
memcmp(90000000,d0000000,4) is ffff8728
memcmp(d0000000,10000000,4) is ffff862c
memcmp(d0000000,50000000,4) is ffff822c
memcmp(d0000000,90000000,4) is 22c

This gives 0x10 < 0x90 < 0x10, and 0x10 < 0x50 < 0x90 < 0xd0 < 0x10.
Since you too use LAHF and CWTL, your code makes the same mistake --
it uses the SF bit instead of the CF bit.  How did you test it?
-- 
G. L. Sicherman
gls at odyssey.att.COM