«

me2 <> writes:

> 0xffffff81 is a 32 bit number. How can it be integer overflow ?

And its value is +0xffffff81, not -0x7f or whatever you are thinking of.
On a host where 'int' is 32-bit, there are only 31 bits to store the
absolute value in, and that is not enough for +0xffffff81. Thus,
overflow.

> Are you saying it will interpret it as an unsigned integer and then
> try to stuff it in a signed int variable and overflow that way ?

No, that's what the host is _not_ required to do, which is why you can't
rely on any particular result. But yes, overflow _into_ the sign bit
is still overflow.

--
Hallvard

me2 writes:
> Changing it to use strtol and a long prevented the overflow. It works
> properly now.

Maybe 'long' is wider than 'int' on your host, then. If that's the
reason it works, it will break on hosts where both are the same size -
which is legal and quite common. (For that matter 'long long' is not
required to be wider than 'int' either, but at least I don't know of any
counterexamples.)

--
Hallvard

Hallvard B Furuseth <> writes:

> me2 writes:
>> Changing it to use strtol and a long prevented the overflow. It works
>> properly now.
>
> Maybe 'long' is wider than 'int' on your host, then. If that's the
> reason it works, it will break on hosts where both are the same size

Then strtol() will set errno to appropriate value and thus program
will print error message instead of printing wrong value (I hope).

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--

>me2 wrote:
>> ... I use sscanf %i to convert argv[1] to an int. Then
>> I cast the int to an unsigned int and do the rest of the manipulation.
>> However, as the above example shows, it doesn't work properly when I input
>> a sign extended octal or hex number.
>>
>> The decimal of 0xffffff81 should be 4294967169, but it isn't. Why ?

In article < .com>
Scorpio <> wrote:
>Because %i is ...

Right start, but:

>only for integers.

wrong details.

All of this family of conversions -- %d, %i, %o, %u, and %x -- are
"for integers", specifically for int unless modified (e.g., %lu is
for long, %hx is for short; note that the hh and ll modifiers are
specific to C99). All of them also convert "as if" by strtol() or
strtoul() -- or in C99 sometimes strtoll() and strtoull() -- with
a base of 16, 10, 8, or 0 depending on the conversion directive;
except that in all cases, the behavior is not defined if the number
would overflow.

Most implementations seem to use the strtol() family of functions
internally, so that they all exhibit that family's "clamping"
behavior of out-of-range inputs. This is the case above: 0xffffff81
is (presuambly) out of range for strtol(), and %i reads a *signed*
integer, so the input is clamped to INT_MAX (or more likely to
LONG_MAX, but that is probably the same as INT_MAX on the target
platform).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Chris Torek <> writes:
[...]
> All of this family of conversions -- %d, %i, %o, %u, and %x -- are
> "for integers", specifically for int unless modified (e.g., %lu is
> for long, %hx is for short; note that the hh and ll modifiers are
> specific to C99).
[...]

Quibble: %d and %i are for int, %o, %u, and %x are for unsigned int.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.