From: Mark Eichin (eichin@tweedledumber.cyGNUs.com)
Date: 08/16/93


From: eichin@tweedledumber.cyGNUs.com (Mark Eichin)
Subject: Re: casts (was SCO cc is broken?)
Date: 16 Aug 1993 17:08:05

Thanks for the exposition of casts; in the code in question, it wasn't
relevant.

:>> switch ( (unsigned int) *(rpkt->dat+1) & ~1) {
:>>rpkt->dat is char*, it fetches the char into AL, then masks EAX and
:>>switches on that... leaving the upper 24 bits of EAX as garbage... so
:>>the switch always fails.

:This description conflicts slightly with itself. `Masking EAX' makes
:the upper 24 bits *not* garbage, if the upper 24 bits are masked away,
:but not if only the low order bit is masked away. I am not
:particularly conversant with Intel 80x86 assembly, but no sample
:compiler output appeared anyway. I suspect that the compilers in
:question make `char's signed, so this means:

Sorry for the poor wording, I should include a larger code sample...
and "masking EAX" wasn't clear... Essentially, what the above is
turned into is
        EAX <- (rpkt->dat+1) ;; EAX is a 32 bit register
        AL <- fetch char from EAX ;; AL is the lower 8 bits of EAX
        EAX <- EAX & ~1 ;; this is what I meant by
                                        ;; "masking EAX"

No sign extension occurs. The compiler used the lower 8-bits of AL to
hold the char value from the buffer, then "magically" used the whole
word as if it contained the value. Sign extending or zero extending
would have been fine -- but (rpkt->dat+1) == 0x1803f7, *(rpkt->dat+1)
== 0x3, ((unsigned int) *(rpkt->dat+1) & ~1) == 0x180302... which
isn't correct by *any* interpretation of the C language.

To reiterate, this was under SCO 3.2v4.0 and ODT 2.0... Thanks to my
complaints here, I'm now aware that some bugs of the above type have
been fixed, and that many of the other problems I had have also been
dealt with in the past year -- so I'll see about getting a newer
release (if it fixes the problems, I should be able to convince my
customers to upgrade as well.)
        Thanks for all of the commentary, especially the calmer and
more polite ones :-)
                                _Mark_ <eichin@athena.mit.edu>
                                MIT Student Information Processing Board
                                Cygnus Support <eichin@cygnus.com>