473,320 Members | 2,098 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

nonzero != 1, right?

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

Thanks,
-trent
Nov 14 '05 #1
28 1481
In article <20*********************@harpo.marx>,
Trent Buck <NO************@bigpond.com> wrote:
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


All operators that return a boolean result are defined to return 0 or
1, so you can do this, or at least could if you didn't mind inverting
the result.
The correct abbreviation would be to `x != y', since your first expression
returns 0 if they're equal.

Note that this only applies to operators and not to the general case;
f'rexample, the isfoo function-or-macros in <ctype.h> are defined to
return nonzero, not necessarily one, as a "yes" value. An easy way
to fold zero-or-nonzero to zero-or-one is two applications of the
`!' operator ("!!val").
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
although come to think of it if you didn't enjoy sounding stupid you wouldn't
be talking about things you don't understand. never mind...
--David C. Ullrich roasts a troll in comp.lang.c++
Nov 14 '05 #2
Trent Buck <NO************@bigpond.com> scribbled the following:
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


There is a difference between treating an integer as a truth value and
vice versa. *Any* non-zero integer value means "true" when used as a
truth value, for example in "if (x)". However, boolean operators such
as "==", "!=", "<", etc. *always* return 1 and no other for "true" and
0 for "false". Therefore the expressions (x==y) and ((x==y)?1:0) are
synonymous. (You got the 0 and 1 wrong in your original expression
plus I'm not too sure about the precedence.)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"'It can be easily shown that' means 'I saw a proof of this once (which I didn't
understand) which I can no longer remember'."
- A maths teacher
Nov 14 '05 #3
Quoth Dave Vandervies on or about 2004-11-11:
Therefore the expression
x == y ? 0 : 1

CANNOT be abbreviated to
x == y
All operators that return a boolean result are defined to return 0 or
1, so you can do this, or at least could if you didn't mind inverting
the result.


Thank you. And whoops, it's past my bedtime.
An easy way to fold zero-or-nonzero to zero-or-one is two applications
of the `!' operator ("!!val").


Yup. I've seen that in the canonical example of divide-and-round-up.

int
dru (int x, int y)
{
return x/y + !!(x%y);
}

....if I'm still awake.
Nov 14 '05 #4
Trent Buck wrote:
...
A boolean expression, evaluates to true or false.
In C language a "boolean" expression evaluates to 0 or 1. The result is
of type 'int'.
In an integer
context, this becomes non-zero or zero, respectively.
According to the above, it is always "in an integer context" and it is
always strictly 0 or 1.
Therefore the expression
x == y ? 0 : 1

CANNOT be abbreviated to
x == y
...


Well, it cannot be abbreviated this way simply because 'x == y'
evaluates to 1 if the values are the same, while the first variant
evaluates to 0.

If you meant 'x == y ? 1 : 0', then this CAN be abbreviated as 'x == y'.

--
Best regards,
Andrey Tarasevich
Nov 14 '05 #5
Dave Vandervies wrote:
[...]
Therefore the expression
x == y ? 0 : 1

CANNOT be abbreviated to
x == y


All operators that return a boolean result are defined to return 0 or
1, so you can do this, or at least could if you didn't mind inverting
the result.
The correct abbreviation would be to `x != y', since your first expression
returns 0 if they're equal.

[...]

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.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Nov 14 '05 #6
In article <41**************@spamcop.net>,
Kenneth Brody <ke******@spamcop.net> wrote:
Dave Vandervies wrote:

All operators that return a boolean result are defined to return 0 or
1, so you can do this, or at least could if you didn't mind inverting
the result.
The correct abbreviation would be to `x != y', since your first expression
returns 0 if they're equal.

[...]

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.)


That'd be all-bits-1 on a twos-complement system, I'm guessing?

That's also a reasonable "true" value, if it's consistent, or at least it
would be if it weren't in violation of the language definition. I seem
to recall that Commodore 64 BASIC did things this way (though I think
they also used zero for true and -1 (bitwise-not-of-true) for false).
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I grant, of course, that our tasks would be much simpler if we could
order up a stock of ideal components.
--William Meyer in comp.lang.c
Nov 14 '05 #7
Dave Vandervies <dj******@csclub.uwaterloo.ca> scribbled the following:
In article <41**************@spamcop.net>,
Kenneth Brody <ke******@spamcop.net> wrote:
Dave Vandervies wrote:
All operators that return a boolean result are defined to return 0 or
1, so you can do this, or at least could if you didn't mind inverting
the result.
The correct abbreviation would be to `x != y', since your first expression
returns 0 if they're equal.[...]

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.)

That'd be all-bits-1 on a twos-complement system, I'm guessing? That's also a reasonable "true" value, if it's consistent, or at least it
would be if it weren't in violation of the language definition. I seem
to recall that Commodore 64 BASIC did things this way (though I think
they also used zero for true and -1 (bitwise-not-of-true) for false).


As a former Commodore 64 BASIC "bedroom programmer", I can definitely say
that Commodore 64 BASIC used 0 for false and -1 for true.
To be more specific, Commodore 64 BASIC and ISO standard C are exactly
alike in this respect - except! - the truth value "true" converted to an
integer is -1 in Commodore 64 BASIC instead of 1.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Nov 14 '05 #8

"Trent Buck" <NO************@bigpond.com> wrote
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

Consider this

int xdoesntequaly(int x, int y)
{
return x - y;
}

Now we can use the value as a boolean

if( xdoesntequaly(1,1234))
{
printf("x doesn't equal y\n")
}

However

int xequalsy(int x, int y)
{
return ( x == y);
}

will always return 1 if x equals y, and 0 otherwise. So the expression x ==
y can here substitute for x == y ? 1 : 0;

However you would be really stupid to write code like that. The goal is to
make your code as clear as possible to read, not to save on keystrokes. So
returning an implict boolean isn't a good idea.
Nov 14 '05 #9
Malcolm wrote:
Consider this

int xdoesntequaly(int x, int y)
{
return x - y;
}


That's no good if x equals INT_MAX and y is negative.

--
pete
Nov 14 '05 #10
Trent Buck <NO************@bigpond.com> wrote:
Could someone please confirm the following

A boolean expression, evaluates to true or false.
Any of the operators < > == != <= >= && || !

returns either 0 (to mean "false") or 1 (to mean "true"). Therefore an
expression where any of the above operators is the "top operator"
evaluates to either 0 or 1.
In an integer
context, this becomes non-zero or zero, respectively.


No. This _is_ already an integer with one of the values 0 or 1 in any
context.

You are confusing "outgoing" values and "incoming" values. "outgoing"
boolean results are always 0 or 1.

If an expression <E1> is used in

if(<E1>)
while(<E1>)
for (E0;E1;E2)
<E1>?:
<E1>||<E2>
<E1>&&<E2>
!<E1>
i.e. if some value is to be *interpreted* as a "boolean", then it is
considered as "false" if it compares equal to 0, otherwise as "true".

Therefore the meaning of is

if (<E1>) if (<E1>!=0)

etc.
--
Horst

Nov 14 '05 #11

"pete" <pf*****@mindspring.com> wrote
Malcolm wrote:
Consider this

int xdoesntequaly(int x, int y)
{
return x - y;
}


That's no good if x equals INT_MAX and y is negative.

The function returns true (non zero) if x != y, zero if x == y.

Consider a 16-bit twos complement machine. The argument is the same for 32
bits, but it is less typing.

INT_MAX = 0x7FFF;
y = -1.

x = y = 0x7FFF + 1 = 0x8000 = INT_MIN = non-zero, so we are OK.

A more interesting case is when one or both are INT_MIN.

INT_MIN is 0x8000
1s compelent INT_MIN is 0x7FFF
2s complement INT_MIN is 0x8000
ie -INT_MIN = INT_MIN !

however if x is not INT_MIN, x + 0x8000 is still non-zero, and INT_MAX is
one less than -INT_MIN.
However if x = INT_MIN

0x8000 + 0x8000 = |overflow bit| 0x0000, or false.

So we are still ok.

However you make a very good point, this is pretty hairy, and realistically
the function should always be writtem return x != y ? 1 : 0;

You may also be right for some very weird non-twos complement architectures,
but I doubt it, because using the subtraction operation to test for equality
is something that many processors do behind the scenes.
Nov 14 '05 #12
Malcolm wrote:
"pete" <pf*****@mindspring.com> wrote
Malcolm wrote:

Consider this

int xdoesntequaly(int x, int y)
{
return x - y;
}
That's no good if x equals INT_MAX and y is negative.


The function returns true (non zero) if x != y, zero if x == y.

Consider a 16-bit twos complement machine. The argument is the same for 32
bits, but it is less typing.

[snip Example] However you make a very good point, this is pretty hairy, and realistically
the function should always be writtem return x != y ? 1 : 0;

You may also be right for some very weird non-twos complement architectures,
but I doubt it, because using the subtraction operation to test for equality
is something that many processors do behind the scenes.


The standard says overflowing signed integers gives UB. Full stop.
However, you can just cast x and y to the corresponding unsigned
type and return an unsigned integer type; no problems with overflow
at all. If you want to return the signed type, you can use the !!
trick and obtain 1 and 0 as possible return values.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #13
Michael Mair wrote:

Malcolm wrote:
"pete" <pf*****@mindspring.com> wrote
Malcolm wrote:
Consider this

int xdoesntequaly(int x, int y)
{
return x - y;
}

That's no good if x equals INT_MAX and y is negative.

The function returns true (non zero) if x != y, zero if x == y.

Consider a 16-bit twos complement machine.
The argument is the same for 32
bits, but it is less typing.

[snip Example]
However you make a very good point, this is pretty hairy,
and realistically
the function should always be writtem return x != y ? 1 : 0;
I think
return x != y;
says it best.

You may also be right for some very
weird non-twos complement architectures,
but I doubt it, because using the subtraction operation
to test for equality
is something that many processors do behind the scenes.


The standard says overflowing signed integers gives UB. Full stop.


That's the point.
However, you can just cast x and y to the corresponding unsigned
type and return an unsigned integer type; no problems with overflow
at all. If you want to return the signed type, you can use the !!
trick and obtain 1 and 0 as possible return values.


--
pete
Nov 14 '05 #14
On Sun, 14 Nov 2004 08:38:53 -0000
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:
"pete" <pf*****@mindspring.com> wrote
Malcolm wrote:
Consider this

int xdoesntequaly(int x, int y)
{
return x - y;
}
That's no good if x equals INT_MAX and y is negative.

The function returns true (non zero) if x != y, zero if x == y.

Consider a 16-bit twos complement machine. The argument is the same
for 32 bits, but it is less typing.


The argument is the same for any integer size whether or not it is 2s
complement. The C standard says integer overflow is undefined behaviour,
so literally anything can happen.
INT_MAX = 0x7FFF;
y = -1.

x = y = 0x7FFF + 1 = 0x8000 = INT_MIN = non-zero, so we are OK.
Or you get an overflow exception causing the program to terminate. Or
you get a carry bit set that causes the next piece of arithmetic you do
to produce the result. Or you are using a processor that limits at
INT_MAX/INT_MIN (I've used C on one) and it is still INT_MAX which I
will admit does act as true.
A more interesting case is when one or both are INT_MIN.

INT_MIN is 0x8000
1s compelent INT_MIN is 0x7FFF
2s complement INT_MIN is 0x8000
ie -INT_MIN = INT_MIN !
Or an exception etc, see above.
however if x is not INT_MIN, x + 0x8000 is still non-zero, and
INT_MAX is one less than -INT_MIN.
However if x = INT_MIN

0x8000 + 0x8000 = |overflow bit| 0x0000, or false.

So we are still ok.
No you are not OK. Your program might have gone bang on overflow.
However you make a very good point, this is pretty hairy, and
realistically the function should always be writtem return x != y ? 1
: 0;

You may also be right for some very weird non-twos complement
architectures, but I doubt it, because using the subtraction operation
to test for equality is something that many processors do behind the
scenes.


It doesn't require a weird non-2s complement architecture. All it
requires is an architecture that provides an exception on integer
overflow.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #15

"Michael Mair" <Mi**********@invalid.invalid> wrote

The standard says overflowing signed integers gives UB. Full stop.
However, you can just cast x and y to the corresponding unsigned
type and return an unsigned integer type; no problems with overflow
at all. If you want to return the signed type, you can use the !!
trick and obtain 1 and 0 as possible return values.

The whole point of the function was to return non-zero but not 1 for a true
condition.
However, yes, I should have remembered that overflows can cause traps,
though on most machines you will of course just get twos complement overflow
as described.
Nov 14 '05 #16
Malcolm wrote:
"Michael Mair" <Mi**********@invalid.invalid> wrote
The standard says overflowing signed integers gives UB. Full stop.
However, you can just cast x and y to the corresponding unsigned
type and return an unsigned integer type; no problems with overflow
at all. If you want to return the signed type, you can use the !!
trick and obtain 1 and 0 as possible return values.

The whole point of the function was to return non-zero but not 1 for a true
condition.


Sorry, I responded to your post. I did not read the whole thread
in order to do that.
Apart from that, if you want to return signed, then you can also
just take the result, say r, and return (signed)(r%a + r%b), a,b>1,
a+b<=INT_MAX+3U, gcd(a,b)>UINT_MAX, or whatever else you can
think of. I only reacted to the invoking of UB.

However, yes, I should have remembered that overflows can cause traps,
though on most machines you will of course just get twos complement overflow
as described.


Yep. UB can also do what you expect, as you know.
This was more for the sake of onlookers more innocent of C knowledge
than you are.

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #17
On Sun, 14 Nov 2004 10:50:46 +0100, Michael Mair wrote:

....
The standard says overflowing signed integers gives UB. Full stop.
However, you can just cast x and y to the corresponding unsigned
type and return an unsigned integer type; no problems with overflow
at all.


But there is a different problem. The standard doesn't require that
UINT_MAX be larger than INT_MAX, they can be equal. In that case pairs of
signed int values (one positive one negative, and maybe INT_MIN,0) will
map to the same unsigned int result. This could result in the code
flagging numbers as equal when they are not.

Lawrence
Nov 14 '05 #18


Lawrence Kirby wrote:
On Sun, 14 Nov 2004 10:50:46 +0100, Michael Mair wrote:
The standard says overflowing signed integers gives UB. Full stop.
However, you can just cast x and y to the corresponding unsigned
type and return an unsigned integer type; no problems with overflow
at all.


But there is a different problem. The standard doesn't require that
UINT_MAX be larger than INT_MAX, they can be equal. In that case pairs of
signed int values (one positive one negative, and maybe INT_MIN,0) will
map to the same unsigned int result. This could result in the code
flagging numbers as equal when they are not.


AFAIR, the standard requires that the standard unsigned integer types
use the full width, that the maximum value U*_MAX=2**width-1, that
the corresponding standard signed integer types use the same number of
bits, hence have a smaller maximal value.
Maybe there is something wrong with this reasoning but I think that
the C99 standard states it similar to the above.
Right now, I do not have the time to look it up but if you can prove
me wrong, feel welcome to do so as I would be interested where this
goes wrong :-)
However, it would be sufficient that UINT_MAX<2*INT_MAX+1.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.

Nov 14 '05 #19
On Mon, 15 Nov 2004 16:32:57 +0100, Michael Mair wrote:


Lawrence Kirby wrote:
On Sun, 14 Nov 2004 10:50:46 +0100, Michael Mair wrote:
The standard says overflowing signed integers gives UB. Full stop.
However, you can just cast x and y to the corresponding unsigned type
and return an unsigned integer type; no problems with overflow at all.
But there is a different problem. The standard doesn't require that
UINT_MAX be larger than INT_MAX, they can be equal. In that case pairs
of signed int values (one positive one negative, and maybe INT_MIN,0)
will map to the same unsigned int result. This could result in the code
flagging numbers as equal when they are not.


AFAIR, the standard requires that the standard unsigned integer types
use the full width,


That is true for unsigned char, but for other unsigned types padding bits
are allowed. See e.g. C99 6.2.6.2p1
that the maximum value U*_MAX=2**width-1, that the corresponding
standard signed integer types use the same number of bits, hence have a
smaller maximal value.


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.

Lawrence
Nov 14 '05 #20


Lawrence Kirby wrote:
On Mon, 15 Nov 2004 16:32:57 +0100, Michael Mair wrote:
Lawrence Kirby wrote:
On Sun, 14 Nov 2004 10:50:46 +0100, Michael Mair wrote:
The standard says overflowing signed integers gives UB. Full stop.
However, you can just cast x and y to the corresponding unsigned type
and return an unsigned integer type; no problems with overflow at all.

But there is a different problem. The standard doesn't require that
UINT_MAX be larger than INT_MAX, they can be equal. In that case pairs
of signed int values (one positive one negative, and maybe INT_MIN,0)
will map to the same unsigned int result. This could result in the code
flagging numbers as equal when they are not.


AFAIR, the standard requires that the standard unsigned integer types
use the full width,

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

that the maximum value U*_MAX=2**width-1, that the corresponding
standard signed integer types use the same number of bits, hence have a
smaller maximal value.

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
--
E-Mail: Mine is a gmx dot de address.

Nov 14 '05 #21
On Fri, 12 Nov 2004 16:22:05 -0500, Kenneth Brody <ke******@spamcop.net>
wrote:
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.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
Nov 14 '05 #22
Michael Mair wrote:

Lawrence Kirby wrote:
On Mon, 15 Nov 2004 16:32:57 +0100, Michael Mair wrote: 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!


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.

--
pete
Nov 14 '05 #23
Trent Buck wrote:
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;
}
Nov 14 '05 #24

On Mon, 15 Nov 2004, E. Robert Tisdale wrote:

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
Nov 14 '05 #25

"pete" <pf*****@mindspring.com> wrote
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?
Nov 14 '05 #26
Malcolm wrote:
"pete" <pf*****@mindspring.com> wrote
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?


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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #27
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:
"pete" <pf*****@mindspring.com> wrote
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?


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
Nov 14 '05 #28
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.

--
pete
Nov 14 '05 #29

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

Similar topics

8
by: Bo Wisén | last post by:
Hi, A project in VB6 recently worked without any problems but now it's complaining when I try to use 'Right$'. In immediate mode, when I'm typing 'print left$("123456",2)' I get the correct...
2
by: Dr. Richard E. Hawkins | last post by:
I've googled around, and asked everyone I know, but I still can't find any reference to anyone else having faced this particular IE bug with floats. I've put a page at...
22
by: Simon | last post by:
Hi, I have written a function to trim char *, but I have been told that my way could be dangerous and that I should use memmove(...) instead. but I am not sure why my code could be 'dangerous'...
3
by: deanfamily11 | last post by:
Ok, here's another problem I'm having. I've tried several different things, but I just can't get anything to be right justified. Any thoughts? #include <iostream> #include <iomanip>...
2
by: Luis Esteban Valencia | last post by:
I can't figure out how to create a validator for values that are nonzero. Something that will allow: 1004 0003 1000 but not:
19
by: ashkaan57 | last post by:
Hi, I have a page in a right-to-left language and I am trying to make some bulleted lists using <ul>, but it puts the bullets to the left. Is there any way I can set the bullets to be on the...
4
by: deLenn | last post by:
Hi, Does scipy have an equivalent to Matlab's 'find' function, to list the indices of all nonzero elements in a sparse matrix? Cheers.
5
by: tshad | last post by:
I have a datagrid that I cannot get to right justify a money amount (which is just a label). No matter what I do - it still right justifies it. <asp:TemplateColumn Visible="true"...
3
by: happyse27 | last post by:
Hi All, I wanted to align the text box for user registration but the code just wont budge... Kindly advise what is wrong? Cheers... Andrew <HTML>
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.