Date:	Wed, 1 Aug 2001 22:49:30 -0600
To:	djgpp AT delorie DOT com
Cc:	Mr Big <esusx AT hotmail DOT com>, Jason Green <news AT jgreen4 DOT fsnet DOT co DOT uk>
Subject:	Re: hex bytes thru BCSerio
Message-ID:	<20010801224930.A10724@taniwha.org>
Mail-Followup-To:	bill, djgpp AT delorie DOT com, Mr Big <esusx AT hotmail DOT com>,
	Jason Green <news AT jgreen4 DOT fsnet DOT co DOT uk>
Mime-Version:	1.0
In-Reply-To:	<epmfmtgussohhuvhaa4jgva6slig77hevj@4ax.com>
User-Agent:	Mutt/1.3.18i
From:	Bill Currie <bill AT taniwha DOT org>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, Aug 01, 2001 at 11:38:10AM +0100, Jason Green wrote:
> [cc'd back to djgpp AT delorie DOT com]
> 
> On Tue, 31 Jul 2001 13:37:46 +0000, you wrote:
> 
> > >I haven't used the BCSerio library myself, but it sounds like you are
> > >looking for unsigned char.  That gives you the range 0x00-0xff and is,
> > >generally speaking, what you want for serial comms.

Wow, it's actually being used still :) There's a more recent version available
from http://taniwha.org/ if you want, and while I no longer have a DOS box* to
test serio (what I call the unreleased code base) with, I'm still happy to
support it.

(* all linux now, I just lurk here still)

> > hum.  so you're saying instead of sending
> > a char as in the ascii characters i normally think of,
> > i can probably do something like this:
> > 
> > unsigned char uc;
> > uc = 0xf3
> > serial_putchar(uc);
> 
> That's what I'm saying, yes.  But also check what serial_putchar() takes
> as a parameter.  If it's an unsigned char then use unsigned char, if it's
> an int then use int. ;)

Actually, it won't matter. I did all my testing using either unsigned char or
just char (I don't remember, but then I don't remember the prototype to
serial_putchar anyway:).

> There are clear rules about signed/unsigned conversions, which I never
> can (be bothered to) remember.  When dealing with bit patterns though,
> (0xf3 is an example of that) then usually an unsigned type is best.

In gcc, it's the signedness of the value being extended that affects the upper
bits. AFAIK, gcc generally doesn't care when going from signed/unsigned to a
smaller type (though I've seen interesting warnings out of gcc 3.0).

All that said, /yes/ unsigned is the best choice when dealing with bit
patterns; /especially/ when shifting. gcc produces better code when right
shifting (>>) unsigned values and right shifting signed values preservs the
uppper bits anyway (eg, -2 >> 1 == -1, -1 >> 1 == -1 (I think, might be 0),
but 0xffffffffu >> 1 == 0x7fffffff (remember: (unsigned int)-1 == 0xffffffffu)).

Bill
-- 
Leave others their otherness. -- Aratak

- Raw text -