Simple C question...entering binary

No. An implicit cast from signed to unsigned does not imply that the bit pattern will be unchanged.

Section 6.3.1.3 from the C99 standard:

"2. Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type."

That would be the case if you cast a bit pattern, as in *(int*) &u = -1; If you just do u = -1; you will always get 'all-bits-one', no matter what the actual representation ist. At least, that's what the Holy Standard says in

6.3.1.3p2.

Stefan

Not that I've ever heard of. Maybe someone has hacked it to target a Unisys ClearPath (descendent of Univac 1107).

I must be particuarly dense today, because I don't see how you get from the wording of 6.3.1.3p2 to the conclusion that you're guaranteed that assigning negative one to an unsigned variable guarantees that the latter will have all bits set.

Never mind, I see it now.

Whoever thought that up obviously never really considered what a compiler for a one's complement machine would have to do to implement this:

unsigned a; int b; [...] a = b;

to handle the case where b is negative at the time of the assignment. (For the case of a literal or other static value, it can be dealt with at compile time.)

The emitted code for the assignment will actually have to test for b being negative and increment the representation.

Sigh.

I don't have my old manuals handy; was the Unisys 10000 series

1's complement?

Michael

6.3.1.3p2 grants that the value you get will be the maximum value the unsigned type can hold, i.e.

unsigned int u = -1;

yields UINT_MAX. That's what you get by adding (UINT_MAX + 1) once to the input value of (-1), to arrive at a value inside the representable range of [0 ..UINT_MAX].

6.2.6.2 effectively defines that UINT_MAX must be of the form (2^n - 1), i.e. all-bits-one. Well, "all-value-bits-one", to be fully picky.

No. Casts are defined in terms of the _value_, not the representation.

It's exactly the other way round.

What do you base this belief on? Are we to assume you're a telepathic time traveler, or how else would you know what people in a conference room did or didn't think, most of twenty years ago?

Yes. So what?

Which is what was wanted.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

I would rather use ~0u. ~0 smells of undefined behaviour although most compilers will do it right.

regards, Mark

I don't know about any 10000 series, but the 1100 series was.

My apologies; I transposed NCR and Unisys in my mind. The NCR 10000 Series was a successor to early NCR architectures contemporary with the Univac 1107.

Michael

I now submit to the public domain, free of charge...

enum { b0000, b0001, b0010, b0011, b0100, b0101, b0110, b0111, b1000, b1001, b1010, b1011, b1100, b1101, b1110, b1111, };

lol

Most of the embedded people did something similar

#define b00000000 0 #define b00000001 1 . . .

before 0b....

was implemented as an extension in most compilers including ours.

w..

CodeDog wrote:

I'd guess that "most of the embedded people" used hex or some sort of (1

I tend to agree with them. I find reading hex (or x

Reading binary numbers is easier when the language lets you separate the binary digits into logical groups, for example with underscores as in the Ada form:

2#10_10110_001000_11111_1_0000000010000#

which is the 32-bit encoding of the SPARC instruction "addx r31,16,r22", grouped according to the logical fields of the encoding. The "_" has no numerical meaning, so the above is the same as:

2#10101100010001111110000000010000#

Perhaps the C compilers that support the 0b... notation should allow some form of grouping like this.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .