Re: How to extract bytes from long?
From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 10/17/03
- Next message: Jonas: "Re: help needed with filnames as command line arguments"
- Previous message: David Bernier: "help needed with filnames as command line arguments"
- In reply to: Samuel Barber: "Re: How to extract bytes from long?"
- Next in thread: Jirka Klaue: "Re: How to extract bytes from long?"
- Reply: Jirka Klaue: "Re: How to extract bytes from long?"
- Reply: Samuel Barber: "Re: How to extract bytes from long?"
- Reply: cody: "Re: How to extract bytes from long?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 17 Oct 2003 03:05:17 -0400 (EDT)
On Fri, 16 Oct 2003, Samuel Barber wrote:
>
> pete wrote in message news:<3F8F5775.27E1@mindspring.com>...
> > Samuel Barber wrote:
> > > (Peter Nilsson) wrote...
> > > > Samuel Barber wrote...
> > > > > pete wrote in message news:<3F8D3896.363F@mindspring.com>...
> > > > > >
> > > > > > printf("%#x\n", value & (unsigned char)-1);
> > > > >
> > > > > I would use ~0 for "all 1s" rather than -1.
> > > >
> > > > That risks a trap representation under C99.
> > >
> > > Nonsense. ~0 is idiomatic C. Aren't you worried about the "risk" that
> > > -1 may not be implemented as all-1s? That is, after all, an
> > > implementation detail. It's not true for sign-magnitude or 1's
> > > complement, for example.
> >
> > You're wrong about everything.
> >
> > ~0 is negative zero in ones complement.
> > Implementations are allowed trap negative zero.
>
> You're just repeating words, without any understanding. There's no
> such thing as "negative zero" (or negative anything) in the context of
> bitwise operations.
It is AFAIK implementation-defined whether the concept of "negative
zero" is meaningful in standard C (depending on the representation
of signed integers).
> How can a bitwise operation trap? It can't.
Of course it can! (Why wouldn't it? And do modern digital computers
perform any operations that *aren't* bitwise, anyway?)
> > -1 is a value, not a bit pattern.
> > The value of negative one, cast to unsigned char, is UCHAR_MAX.
To clarify pete's point:
(uchar)-1 == (uchar)-((int)1) == (-(int)1)+UCHAR_MAX == UCHAR_MAX-1
...which is guaranteed to have an all-ones bit pattern, regardless
of padding or n's-complement.
> Hello? The point is that -1 is ***being used as*** a bit pattern.
Then it's being used incorrectly. -1 is *not* a bit pattern, it's
an integer expression equal to the additive inverse of the integer 1.
It doesn't have a "bit pattern" per se.
> The intent is to get "all 1s", which is true if the integer
> representation is 2's complement; that's an implicit assumption
> of the code.
If that *were* an implicit assumption of the code, then the code
would be broken. But it's not. Pete's code AFAICT doesn't assume
anything earth-shattering about the integer representations used
by the target system.
> (This is the best reason not to use -1: the intent is not
> perfectly clear).
However, it *does* produce the right answer, which is a point in
its favor. ~0 might trap, and in any case I think (unsigned char)-1
has a bit more aesthetic value to it (YMMV, of course).
And if you want everything to be *perfectly* clear, then you might
want to consider a different programming language. C is just
full of 'for (i=0; a[i]; ++i)'s and 'while (*s++ = *t++)'s; if
a simple -1 throws you, then you're in trouble. :-)
-Arthur
- Next message: Jonas: "Re: help needed with filnames as command line arguments"
- Previous message: David Bernier: "help needed with filnames as command line arguments"
- In reply to: Samuel Barber: "Re: How to extract bytes from long?"
- Next in thread: Jirka Klaue: "Re: How to extract bytes from long?"
- Reply: Jirka Klaue: "Re: How to extract bytes from long?"
- Reply: Samuel Barber: "Re: How to extract bytes from long?"
- Reply: cody: "Re: How to extract bytes from long?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
