Date: Wed, 1 Aug 2001 22:49:30 -0600 To: djgpp AT delorie DOT com Cc: Mr Big , Jason Green Subject: Re: hex bytes thru BCSerio Message-ID: <20010801224930.A10724@taniwha.org> Mail-Followup-To: bill, djgpp AT delorie DOT com, Mr Big , Jason Green Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: Bill Currie 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 Precedence: bulk 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