473,734 Members | 2,824 Online

# trap representation

What does a trap representation mean in the standard?
And how can ~0 cause a trap representation? Could someone point out
the relevant sections in the standard?
Nov 13 '05
18 9080
Malcolm wrote:
I believe it is permitted to disallow all bits set for
unsigned types also, so INT_MAX might be 0xFFFE.

The minimum allowed value for INT_MAX is a little higher.
Are you familiar with limits.h ?

--
pete
Nov 13 '05 #11
pete wrote:

Malcolm wrote:
I believe it is permitted to disallow all bits set for
unsigned types also, so INT_MAX might be 0xFFFE.

The minimum allowed value for INT_MAX is a little higher.
Are you familiar with limits.h ?

I meant UINT_MAX,
and I think I completely misunderstood what you were saying.

--
pete
Nov 13 '05 #12
"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote in message news:<bj******* ***@newsg2.svr. pol.co.uk>...
....
A machine doesn't have to use twos complement for negatives, and I believe it
is permitted to disallow all bits set for unsigned types also,
Only if the unsigned type is padded. For unsigned integers, all value
bits contribute and the order of the range of values is a power of
two.
so INT_MAX might be 0xFFFE.

This is also theoretically true, depending on your view of the
standards, but not actually related to unsigned types. Note that
UINT_MAX must be a value equal or greater than 65535 (0xFFFF).

--
Peter
Nov 13 '05 #13
Fred L. Kleinschmidt wrote:

Lew Pitcher wrote:
On Thu, 11 Sep 2003 19:08:19 +0100, "Malcolm" <ma*****@55bank .freeserve.co.u k>
wrote:

"Mantorok Redgormor" <ne*****@tokyo. com> wrote in message

What does a trap representation mean in the standard?
And how can ~0 cause a trap representation? Could someone point
out the relevant sections in the standard?
A trap representaion is an illegal value for a variable to hold.

[snip]
All bits set is allowed as a trap value. Thus ~0 could potentially trap.

More specifically, on a ones-complement machine, all bits set is a potential
trap representation, as it represents the value you get when you evaluate
negative zero {(-0)}.

On a two's complement machine, -0 == all bits zero == 0
On a one's complement machine, -0 == all bits one != 0
On either machine ~0 == all bits one != 0

But the C abstract machine doesn't recognize a difference between 0 and -0, thus
making the one's complement expression a potential trap value ("cant happen").

--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')

For integer types (signed or unsigned, short or long), would all ones be
an illegal value? I can see it for floats/doubles, but for integers???

On every platform I have encoutered with 16-bit shorts and 32-bit ints,
USHRT_MAX is 65535, which is sixteen ones in binary, and MAX_INT (or
MAX_INT) is 4294967295 which is 32 ones. For these cases, "all ones"
must be a legal value.

You've been working on twos-complement systems, I see.
Ones-complement is different.

On a twos-complement system
-n = ~n + 1

That is to say, if

0 == 000
1 == 001
2 == 010
3 == 011

then

-1 == (~ 001) + 1 == 110 + 1 == 111
-2 == (~ 010) + 1 == 101 + 1 == 110
-3 == (~ 011) + 1 == 100 + 1 == 101

and

-0 == (~ 000) + 1 == 111 + 1 == 000 (discarding the overflow)

However, on a ones-complement system,
-n = ~n

That is to say, if
0 == 000
1 == 001
2 == 010
3 == 011

then

-1 == (~ 001) == 110
-2 == (~ 010) == 101
-3 == (~ 011) == 100

and
-0 == (~ 000) == 111

But, mathematically, -0 == 0, so 111 must equal 000

So, either 111 is an illegal value (representing a number that has no legal
existance), and thus a "trap value", or the language must arrange to make -0
equal to 0.

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

Nov 13 '05 #14
In article <ho***********@ merlin.l6s4x6-4.ca>
Lew Pitcher <lp******@sympa tico.ca> writes (in part):
However, on a ones-complement system,
-n = ~n [snippage; hence] -0 == (~ 000) == 111

But, mathematically, -0 == 0, so 111 must equal 000

So, either 111 is an illegal value (representing a number that has no legal
existance), and thus a "trap value", or the language must arrange to make -0
equal to 0.

Incidentally, this is not *necessarily* a purely theoretical
discussion. The Univac 1100 series of computers (whose native OS
was EXEC-8, at least as used in the University of Maryland) had
9-bit "char", 18-bit "short", 36-bit "int", and used ones' complement
arithmetic, in their C compiler(s). This was all before the first
C standard came out in 1989, and I do not know if the C compiler(s)
was/were ever made C89-conformant -- but the machines did exist
and did have at least one C compiler.

I never used these machine enough to learn precisely how they
treated negative zero in integer operations. One might note,
however, that machines with ones' complement or sign-and-magnitude
integer arithmetic avoid a nasty problem that occurs in today's
two's complement hardware:

int x = INT_MIN;
printf("x = %d\n", x); /* outputs -32768 or -2147483648, for instance */
x = -x; /* what happens here? */
printf("-x = %d\n", x); /* what gets printed? */

If you try this on your machine (for the generic "you" reading
this), you will probably see that -x is *still* negative, and
x == -x. If your machine used one of the other two representations ,
-x would be positive.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #15

"Chris Torek" <no****@elf.eng .bsdi.com> wrote in message
news:bj******** **@elf.eng.bsdi .com...
In article <ho***********@ merlin.l6s4x6-4.ca>
Lew Pitcher <lp******@sympa tico.ca> writes (in part):
However, on a ones-complement system,
-n = ~n [snippage; hence]
-0 == (~ 000) == 111

But, mathematically, -0 == 0, so 111 must equal 000

So, either 111 is an illegal value (representing a number that has no legalexistance), and thus a "trap value", or the language must arrange to make -0equal to 0.

Incidentally, this is not *necessarily* a purely theoretical
discussion. The Univac 1100 series of computers (whose native OS
was EXEC-8, at least as used in the University of Maryland) had
9-bit "char", 18-bit "short", 36-bit "int", and used ones' complement
arithmetic, in their C compiler(s). This was all before the first
C standard came out in 1989, and I do not know if the C compiler(s)
was/were ever made C89-conformant -- but the machines did exist
and did have at least one C compiler.

I have been told that Univac still builds and sells ones complement
machines. I have no idea about C compilers for them, though. CDC machines
are/were also ones complement. There are people working on emulators, I
don't know how many real machines are still running.
I never used these machine enough to learn precisely how they
treated negative zero in integer operations. One might note,
however, that machines with ones' complement or sign-and-magnitude
integer arithmetic avoid a nasty problem that occurs in today's
two's complement hardware:

int x = INT_MIN;
printf("x = %d\n", x); /* outputs -32768 or -2147483648, for instance */ x = -x; /* what happens here? */
printf("-x = %d\n", x); /* what gets printed? */

If you try this on your machine (for the generic "you" reading
this), you will probably see that -x is *still* negative, and
x == -x. If your machine used one of the other two representations ,
-x would be positive.

Early in my Fortran programming years, B.C. (Before C was invented), I had
a program to print out
2**I in a loop, using 16 bit integers and noticed the -32768 followed by
zeros. It didn't take long to figure out what happened, but it was
surprising at first. Note that Fortran, unlike C, has integer
exponentiation, both integer to integer power and real to integer power.

I only recently learned that it is allowable for -INT_MAX-1 to be a trap
representation for twos complement machines. That is one answer to the
problem, though I think it only makes things worse.

-- glen
Nov 13 '05 #16
Chris Torek wrote:
.... snip ...
I never used these machine enough to learn precisely how they
treated negative zero in integer operations. One might note,
however, that machines with ones' complement or sign-and-magnitude
integer arithmetic avoid a nasty problem that occurs in today's
two's complement hardware:

int x = INT_MIN;
printf("x = %d\n", x); /* outputs -32768 or -2147483648, for instance */
x = -x; /* what happens here? */
printf("-x = %d\n", x); /* what gets printed? */

If you try this on your machine (for the generic "you" reading
this), you will probably see that -x is *still* negative, and
x == -x. If your machine used one of the other two representations ,
-x would be positive.

There are definite advantages, in some cases, for the use of 1's
complement arithmetic. By making the basic arithmetic operation
a subtractor, one can prevent the occurence of -0, allowing it to
be a trap representation. The advantages show up better in
decimal machines using 9's complement, but not for C standards
compliance.

In your example, there is no reason why INT_MIN should not be odd
on a 2's complement machine, AFAICT. This again allows INT_MIN-1
to be a trap representation, but is much more awkward that the
equivalent on a 1's comp. machine.

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.
Nov 13 '05 #17
j wrote:

Shouldn't that be sign-extended instead of one's complement? I don't think
one's complement is proper terminology.

The Standard uses the term "one's complement" in section
6.2.6.2, paragraph 2. That's authoritative on comp.lang.c.

However, Donald Knuth writes "ones' complement" in "The
Art of Computer Programming, Volume II: Seminumerical Algorithms,"
section 4.1. In the 1999 edition of that book, he goes so far
as to insert a short note explaining why "one's" is wrong and
"ones'" is right, and why the opposite situation holds for
"two's complement." For the world beyond comp.lang.c, Knuth
is considered authoritative or at least encyclopedic.

Summary: Two authorities disagree, and you'll have to choose
between them for yourself. Or perhaps adopt an entirely different
authority, like Lawrence Welk: "A-one-an'-a-two's complement."

--
Er*********@sun .com
Nov 13 '05 #18

"Eric Sosman" <Er*********@su n.com> wrote in message
news:3F******** ******@sun.com. ..
j wrote:

Shouldn't that be sign-extended instead of one's complement? I don't think one's complement is proper terminology.

The Standard uses the term "one's complement" in section
6.2.6.2, paragraph 2. That's authoritative on comp.lang.c.

However, Donald Knuth writes "ones' complement" in "The
Art of Computer Programming, Volume II: Seminumerical Algorithms,"
section 4.1. In the 1999 edition of that book, he goes so far
as to insert a short note explaining why "one's" is wrong and
"ones'" is right, and why the opposite situation holds for
"two's complement." For the world beyond comp.lang.c, Knuth
is considered authoritative or at least encyclopedic.

Summary: Two authorities disagree, and you'll have to choose
between them for yourself. Or perhaps adopt an entirely different
authority, like Lawrence Welk: "A-one-an'-a-two's complement."

--
Er*********@sun .com

I guess some people use it to just constrast with two's complement. I guess
I'll use one's complement here to prevent any confusion since it is used in
the standard. :)
Nov 13 '05 #19

This thread has been closed and replies have been disabled. Please start a new discussion.