On 2017-03-08, at 09:41, Phil Smith wrote: > Charles Mills wrote: >> One thing about little-endian I have observed of relevance to software >> writers: if I expect you to pass me a halfword and instead you pass me a >> fullword, then the code will probably work most of the time. Whether that is >> a benefit or a liability depends upon one's point of view. > I come down strongly on the “Liability” side: “It works until you enter a > really big number” sounds like just asking for obscure failures. Obviously > with big-endian, the opposite is also true: if I expect a fullword and you > pass a halfword, it’ll sort of work with big numbers, > Um. No. Not unless the top halves and bottom halves are identical.
> fail with smaller. But that’s an easier to detect failure (“I passed 100000 > and it said I passed 34 thousand and change”), plus testing will start with > small values and thus it’ll show up immediately; the little-endian case will > work fine until the numbers get big and it doesn’t. > A colleague perferred to test with big-endian in order to detect operand type errors early. I was exposed to a dreadful ISV compiler which promoted char, short, and int formal parameters to long, as is the convention in absence of a function prototype. (Ah, the bad old days!) But then the "&" (pointer to) operator pointed to the high end of the long in a big-endian system. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
