COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### Re: bitwise absolute value

• Follow

```# That works, but it assumes 32 bit integers. Is there a
# portable/standard way to do this?  Or are ANSI integers

assert(-1==~0); /*twos complement*/

signx = x>>(sizeof x*CHAR_BIT)
absx = (x ^ signx)-signx;

--
Derk Gwen http://derkgwen.250free.com/html/index.html
Death is the worry of the living. The dead, like myself,
only worry about decay and necrophiliacs.
```
 0
Reply derkgwen (343) 9/10/2003 5:18:23 AM

```Derk Gwen <derkgwen@hotpop.com> wrote:
> # That works, but it assumes 32 bit integers. Is there a
> # portable/standard way to do this?  Or are ANSI integers
>
> assert(-1==~0); /*twos complement*/
>
> signx = x>>(sizeof x*CHAR_BIT)
> absx = (x ^ signx)-signx;

That makes two assumptions, only one of which your assert() checks (the
other is that >> fills using the sign bit).

- Kevin.

```
 0
Reply Kevin 9/10/2003 5:29:07 AM

```Kevin Easton wrote:
>
> Derk Gwen <derkgwen@hotpop.com> wrote:
> > # That works, but it assumes 32 bit integers. Is there a
> > # portable/standard way to do this?  Or are ANSI integers
> >
> > assert(-1==~0); /*twos complement*/
> >
> > signx = x>>(sizeof x*CHAR_BIT)
> > absx = (x ^ signx)-signx;
>
> That makes two assumptions,
> only one of which your assert() checks (the
> other is that >> fills using the sign bit).

It's not as good as that.
x>>(sizeof x*CHAR_BIT) is shifted too far, and undefined behavior.
No padding bits is also assumed.

--
pete
```
 0
Reply pfiland (6613) 9/10/2003 9:35:32 AM

```On Wed, 10 Sep 2003, pete wrote:

> > > assert(-1==~0); /*twos complement*/
> > >
> > > signx = x>>(sizeof x*CHAR_BIT)
> > > absx = (x ^ signx)-signx;
> >
> > That makes two assumptions,
> > only one of which your assert() checks (the
> > other is that >> fills using the sign bit).
>
> It's not as good as that.
> x>>(sizeof x*CHAR_BIT) is shifted too far, and undefined behavior.
> No padding bits is also assumed.

unsigned x_is_neg = (unsigned)x/(1u+-1u/2u);
absx = ((unsigned)x ^ -x_is_neg)+x_is_neg;

```
 0
Reply jwuolijo (88) 9/10/2003 10:25:12 AM

```pete <pfiland@mindspring.com> wrote:
> Kevin Easton wrote:
>>
>> Derk Gwen <derkgwen@hotpop.com> wrote:
>> > # That works, but it assumes 32 bit integers. Is there a
>> > # portable/standard way to do this?  Or are ANSI integers
>> >
>> > assert(-1==~0); /*twos complement*/
>> >
>> > signx = x>>(sizeof x*CHAR_BIT)
>> > absx = (x ^ signx)-signx;
>>
>> That makes two assumptions,
>> only one of which your assert() checks (the
>> other is that >> fills using the sign bit).
>
> It's not as good as that.
> x>>(sizeof x*CHAR_BIT) is shifted too far, and undefined behavior.

True.

> No padding bits is also assumed.

Padding bits are invisible to shifts (x >> 1 is always x / 2 for +ve x,
regardless of padding bits).  In general padding bits are only a concern
when type punning is taking place.

- Kevin.

```
 0
Reply Kevin 9/10/2003 12:43:06 PM

```On Wed, 10 Sep 2003, Kevin Easton wrote:
>
> pete <pfiland@mindspring.com> wrote:
> > Kevin Easton wrote:
> >>
> >> Derk Gwen <derkgwen@hotpop.com> wrote:
> >> > # That works, but it assumes 32 bit integers. Is there a
> >> > # portable/standard way to do this?  Or are ANSI integers
> >> >
> >> > assert(-1==~0); /*twos complement*/
> >> >
> >> > signx = x>>(sizeof x*CHAR_BIT)
> >> > absx = (x ^ signx)-signx;
> >>
> >> That makes two assumptions,
> >> only one of which your assert() checks (the
> >> other is that >> fills using the sign bit).
> >
> > It's not as good as that.
> > x>>(sizeof x*CHAR_BIT) is shifted too far, and undefined behavior.
> > No padding bits is also assumed.
>
> Padding bits are invisible to shifts (x >> 1 is always x / 2 for +ve x,
> regardless of padding bits).  In general padding bits are only a concern
> when type punning is taking place.

Yes, but in this case the number of padding bits affects *how far*
we need to right-shift the value.  If there are no padding bits,
then the value of (sizeof x*CHAR_BIT) is correct.  If there is one
padding bit per byte, then we really need to shift by
(sizeof x * (CHAR_BIT-1)); if there is one padding bit per integer,
maybe as a parity bit, then we mean (sizeof x * CHAR_BIT - 1); and
so on.

(N869 sections 6.5.7#3, 6.2.6.2#4)

-Arthur
```
 0
Reply ajo12 (264) 9/10/2003 4:10:53 PM

```Arthur J. O'Dwyer wrote:
>
> On Wed, 10 Sep 2003, Kevin Easton wrote:
> >
> > pete <pfiland@mindspring.com> wrote:

> > > x>>(sizeof x*CHAR_BIT) is shifted too far, and undefined behavior.

> If there are no padding bits,
> then the value of (sizeof x*CHAR_BIT) is correct.

N869
6.5.7  Bitwise shift operators
[#3]

The integer promotions are performed  on  each  of  the
operands.   The  type  of the result is that of the promoted
left operand.  If the value of the right operand is negative
or  is  greater  than  or

equal to the width of the promoted left operand,
^^^^^

the behavior is undefined.

--
pete
```
 0
Reply pfiland (6613) 9/11/2003 12:10:16 AM

```On Thu, 11 Sep 2003, pete wrote:
>
> Arthur J. O'Dwyer wrote:
> > On Wed, 10 Sep 2003, Kevin Easton wrote:
> > > pete <pfiland@mindspring.com> wrote:
>
> > > > x>>(sizeof x*CHAR_BIT) is shifted too far, and undefined behavior.
>
> > If there are no padding bits,
> > then the value of (sizeof x*CHAR_BIT) is correct.
>
> N869
> 6.5.7  Bitwise shift operators
>        [#3]
[re: sizeof x*CHAR_BIT is undefined behavior]

Oh -- of course.  Sorry.  Subtract one from each of my examples;
e.g., if there are no padding bits, then (sizeof x*CHAR_BIT)-1 is
correct; if there's one padding bit per byte, then
(sizeof x*(CHAR_BIT-1)-1 is correct; et cetera.

-Arthur

```
 0
Reply ajo12 (264) 9/11/2003 1:12:11 AM

7 Replies
71 Views

(page loaded in 0.135 seconds)

Similiar Articles:

7/2/2012 3:19:51 AM

 Reply: