nonzero != 1, right?

[Michael Mair]

That is true for unsigned char, but for other unsigned types padding bits
are allowed. See e.g. C99 6.2.6.2p1




The requirement on range is that C99 6.2.5p9:

"The range of nonnegative values of a signed integer type is a subrange of
the corresponding unsigned integer type, and the representation of the
same value in each type is the same."

So an implementation of unsigned types which is the same as the
corresponding signed type except that the sign bit is a padding bit is
valid, except for unsigned char.

There are minimum range limits e.g. UINT_MAX must be at least 65535. So if
unsigned int was 16 bits wide it would have to use all bits as value bits.
But a 32 bit wide one does not.

Thank you for the information!

Cheers
Michael

 

[Kevin D. Quitt]

Note that, years ago, I worked on a system where boolean expressions
returned either 0 or -1. (I'm sure this is before ANSI stepped in and
said it must be 0 or 1.)

On the VAX, when it first came out (perhaps later, I don't know), only the
lsb was tested to determine the boolean value.

 

[pete]

Thank you for the information!

That's the trickey part of K&R2 Exercise 3-4, itoa()
The standard doesn't guarantee that there is any integer type
capable of representing the magnitude of INT_MIN.

 

[E. Robert Tisdale]

Could someone please confirm the following

A boolean expression, evaluates to true or false.
In an integer context, this becomes non-zero or zero, respectively.

Therefore the expression
x == y? 0: 1

CANNOT be abbreviated to
x == y

This is a boolean expression.
It evaluates to either 'true' or 'false'.
C++ programmers know that,
when true is converted to an int, its value is 1 and
when false is converted to an int, its value is 0.
C programmers are always confused.

To avoid confusion, you should make the distinction
between a boolean and an int explicit:

#include <stdbool.h>

bool equal(int x, int y) {
return x == y;
}

int select(int x, int y) {
return (x != y)? 0: 1;
}

 

[Arthur J. O'Dwyer]

To avoid confusion, you should make the distinction
between a boolean and an int explicit:

bool equal(int x, int y) {
return x == y;
}

In case it isn't already abundantly obvious, Trollsdale is making a
joke here. The above advice is bad, and the code is worse.

-Arthur

 

[Malcolm]

That's the trickey part of K&R2 Exercise 3-4, itoa()
The standard doesn't guarantee that there is any integer type
capable of representing the magnitude of INT_MIN.

Which raise the following problem.

int manhattandist(int x1, int y1, it x2, int y2)
{
return abs(x1-x2) + abs(y1 - y2);
}

perfectly unexceptional code. You might expect to get an error if distances
are so extreme that the answer overflows. This is a little glitch in the
language.

But what if x2 is INT_MIN, and the act of negating it causes an overflow?
Will this be documented? Should it be?

 

[Michael Mair]

Which raise the following problem.

int manhattandist(int x1, int y1, it x2, int y2)
{
return abs(x1-x2) + abs(y1 - y2);
}

perfectly unexceptional code. You might expect to get an error if distances
are so extreme that the answer overflows. This is a little glitch in the
language.

But what if x2 is INT_MIN, and the act of negating it causes an overflow?
Will this be documented? Should it be?

UB. Unfortunately, no. IMO, even though it would be nice: No.
For big ranges, I use long rather than int and restrict the
range to -(LONG_MAX/2) to LONG_MAX/2 with the respective range
checks after critical operations.

Cheers
Michael

 

[Richard Bos]

Which raise the following problem.

int manhattandist(int x1, int y1, it x2, int y2)
{
return abs(x1-x2) + abs(y1 - y2);
}

perfectly unexceptional code. You might expect to get an error if distances
are so extreme that the answer overflows. This is a little glitch in the
language.

But what if x2 is INT_MIN, and the act of negating it causes an overflow?
Will this be documented?

Undefined behaviour. But note that the code you present does not negate
x2; it subtracts x2 from x1. If x1<0, and x2==INT_MIN, then x1-x2 does
not cause overflow and should work fine.

Should it be?

I'm in two minds about that. OT1H, not requiring overflow detection is
good; it probably allows the generation of more efficient object code.
OTOH, allowing the program to crash outright is not nice; unspecified
behaviour might have been better. OTGH, it's probably not trivial to
formulate a water-tight rule which doesn't hamper optimisers unduly.

Richard

 

[pete]

Malcolm wrote:

But what if x2 is INT_MIN,
and the act of negating it causes an overflow?

if x2 is of type int and -INT_MAX > x2, then (-x2) is undefined.

Will this be documented? Should it be?

No.