trap representation

[Mantorok Redgormor]

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?

[Malcolm]

"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. The
platform detects such values, and then terminates the program with an error
message. For instance, a communist OS may decide that ascii dollar ($) is
illegal in strings. When you try to assign '$' to a char, it could terminate
with the error message "capitalist pig program".

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

[Glen Herrmannsfeldt]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bj**********@newsg4.svr.pol.co.uk...

"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. The
platform detects such values, and then terminates the program with an

error message. For instance, a communist OS may decide that ascii dollar ($) is
illegal in strings. When you try to assign '$' to a char, it could terminate with the error message "capitalist pig program".

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

Well, that could only be true with padding bits, or using other than twos
complement arithmetic.

The WATFIV Fortran compiler detected the use of undefined variables by
initializing all bytes to X'81' (0x81 in C) and then checking for that. It
worked pretty well, except for CHARACTER variables, in that it was pretty
unlikely to occur accidentally.

I believe that there may have been ones complement machines that would trap
on ~0, which is -0, but I wouldn't worry too much about them.

There was a suggestion not so long ago to detect twos complement machines
with:

#if ~0==-1

which would be compile time, and I have no idea what the preprocessor says
about traps.

#if ~1==-2

would work just as well, though.

-- glen

[Ben Pfaff]

"Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bj**********@newsg4.svr.pol.co.uk...

"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. The
platform detects such values, and then terminates the program with an

error

message. For instance, a communist OS may decide that ascii dollar ($) is
illegal in strings. When you try to assign '$' to a char, it could

terminate

with the error message "capitalist pig program".

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

Well, that could only be true with padding bits, or using other than twos
complement arithmetic.

C99 supports ones' complement and sign-magnitude as well as two's
complement, so portable code can't assume that two's complement
is in use.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman

[Lew Pitcher]

On Thu, 11 Sep 2003 19:08:19 +0100, "Malcolm" <ma*****@55bank.freeserve.co.uk>
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')

[j]

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

"Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bj**********@newsg4.svr.pol.co.uk...

"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. The
platform detects such values, and then terminates the program with an

error

message. For instance, a communist OS may decide that ascii dollar ($) is illegal in strings. When you try to assign '$' to a char, it could

terminate

with the error message "capitalist pig program".

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

trap.
Well, that could only be true with padding bits, or using other than twos complement arithmetic.

C99 supports ones' complement and sign-magnitude as well as two's
complement, so portable code can't assume that two's complement
is in use.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman

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

[Ben Pfaff]

"j" <ja****@bellsouth.net> writes:

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

See C99 6.2.6.2:

- the sign bit has the value -(2N - 1) (one's complement).

--
Bite me! said C.

[Fred L. Kleinschmidt]

Lew Pitcher wrote:

On Thu, 11 Sep 2003 19:08:19 +0100, "Malcolm" <ma*****@55bank.freeserve.co.uk>
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.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 [phone]

[Malcolm]

"Fred L. Kleinschmidt" <fr*****************@boeing.com> wrote in

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???

It's more a theoretical problem than anything you are likely to encounter. 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, so INT_MAX
might be 0xFFFE.

[Martin Dickopp]

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

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

What does a trap representation mean in the standard?
6.2.6.1#5: Certain object representations need not represent a value
of the object type. If the stored value of an object has such a
representation and is read by an lvalue expression that does not have
character type, the behavior is undefined. If such a representation is
produced by a side effect that modifies all or any part of the object by
an lvalue expression that does not have character type, the behavior is
undefined. Such a representation is called a trap representation.
And how can ~0 cause a trap representation? Could someone point out
the relevant sections in the standard?

6.2.6.2#2: [...] Which of these [sign and magnitute, two's complement,
one's complement] applies is implementation-defined, as is whether the
value with sign bit 1 and all value bits zero (for the first two), or
with sign bit and all value bits 1 (for one's complement), is a trap
representation or a normal value. In the case of sign and magnitude and
one's complement, if this representation is a normal value it is called a
negative zero.
A trap representaion is an illegal value for a variable to hold. The
platform detects such values, and then terminates the program with an
error message.

Actually, the implementation is not required to detect a trap
representation. Using it causes undefined behavior.

Martin

[pete]

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

[pete]

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.
Sorry about that.

--
pete

[Peter Nilsson]

"Malcolm" <ma*****@55bank.freeserve.co.uk> 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

[Lew Pitcher]

Fred L. Kleinschmidt wrote:

Lew Pitcher wrote:

On Thu, 11 Sep 2003 19:08:19 +0100, "Malcolm" <ma*****@55bank.freeserve.co.uk>
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.

[Chris Torek]

In article <ho***********@merlin.l6s4x6-4.ca>
Lew Pitcher <lp******@sympatico.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) [phone]
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.

[Glen Herrmannsfeldt]

"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******@sympatico.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

[LibraryUser]

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.

[Eric Sosman]

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

[j]

"Eric Sosman" <Er*********@sun.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. :)