Integer promotion and overflow

[Russell Shaw]

Hi,
I'm using gcc-3.4.3 on a linux pc. The ints and long ints are 32 bits
and long long ints are 64 bits.

When i have:

int num=9600;
long long int reg=(long long)8000000000 00/(5000000*num);

the denominator overflows and gives an incorrect answer: reg=1059
With an extra cast:

long long int reg=(long long)8000000000 00/((long long)5000000*nu m);

i get: reg=16
If the numerator is a long long int, should the denominator be
automatically promoted to a long long int?

[jacob navia]

Russell Shaw wrote:

Hi,
I'm using gcc-3.4.3 on a linux pc. The ints and long ints are 32 bits
and long long ints are 64 bits.

When i have:

int num=9600;
long long int reg=(long long)8000000000 00/(5000000*num);

the denominator overflows and gives an incorrect answer: reg=1059
With an extra cast:

long long int reg=(long long)8000000000 00/((long long)5000000*nu m);

i get: reg=16
If the numerator is a long long int, should the denominator be
automatically promoted to a long long int?

lcc-win32 gives the same answer as gcc. The problem is
that the denomitar *is* converted to long long. The
compiler does:

long long int reg=(long long)8000000000 00/(long long)(5000000*n um);

Neither gcc nor lcc-win32 realize that the denominator is an
expression, converting each member to the highest rank type.

Maybe there are compilers that clever, but I would not rely
on it, and would add the cast.

jacob

[Eric Sosman]

Russell Shaw wrote:

Hi,
I'm using gcc-3.4.3 on a linux pc. The ints and long ints are 32 bits
and long long ints are 64 bits.

When i have:

int num=9600;
long long int reg=(long long)8000000000 00/(5000000*num);

the denominator overflows and gives an incorrect answer: reg=1059
With an extra cast:

long long int reg=(long long)8000000000 00/((long long)5000000*nu m);

i get: reg=16
If the numerator is a long long int, should the denominator be
automatically promoted to a long long int?

Yes. But the denominator (in the first form) is itself
the product of two factors of type `int', so it is calculated
in `int' arithmetic. The product is too large for an `int',
so it overflows and is chopped down to 32 bits (on your system;
C itself doesn't guarantee what happens). Then the already-
damaged value is promoted to `long long' for the division, but
it's too late: the denominator is much smaller than intended,
so the quotient comes out much too large.

In the second form, the 5000000 term is converted to `long
long' by the cast operator. The denominator is then the product
of a `long long' and an `int', so `num' is converted to `long
long' and the multiplication is carried out in `long long'
arithmetic and does not overflow. Then the division takes
place, and everything comes out as expected.

A better way to write this would be to make the constants
`long long' to begin with:

long long int reg = 800000000000LL / (5000000LL * num);

--
Eric Sosman
es*****@acm-dot-org.invalid

[Chris Croughton]

On Sun, 02 Jan 2005 17:26:27 +0100, jacob navia
<ja***@jacob.re mcomp.fr> wrote:

lcc-win32 gives the same answer as gcc. The problem is
that the denomitar *is* converted to long long. The
compiler does:

long long int reg=(long long)8000000000 00/(long long)(5000000*n um);

Neither gcc nor lcc-win32 realize that the denominator is an
expression, converting each member to the highest rank type.
Nor should they, C is specified such that conversions occur only when
they are forced because the types are dissimilar (or when forced with a
cast). For instance:

long long denom = 5000000 * num;

will give the same overflow, because it is specified that 5000000*num is
calculated and only then converted to a long long.
Maybe there are compilers that clever, but I would not rely
on it, and would add the cast.

It would not be 'clever', it would be against the standard. There are
other /languages/ which have the semantics the other way round, so that
expression type is propagated left to right (Algol and Pascal, I
believe, do that), but any C compiler must do the sub-expressions first
and promote the types only when it is necessary because the other
operand is a higher type.

Chris C

[Keith Thompson]

Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes:

I'm using gcc-3.4.3 on a linux pc. The ints and long ints are 32 bits
and long long ints are 64 bits.

When i have:

int num=9600;
long long int reg=(long long)8000000000 00/(5000000*num);

the denominator overflows and gives an incorrect answer: reg=1059

With an extra cast:

long long int reg=(long long)8000000000 00/((long long)5000000*nu m);

i get: reg=16

If the numerator is a long long int, should the denominator be
automatically promoted to a long long int?

The evaluation of an expression is not affected by the context in
which it appears. Think of expressions, including their
subexpressions, as being evaluated bottom-up, not top-down.

The right operand of the "/" operator is:

(5000000*num)

Each operand of the "*" is of type int, so it's an int-by-int
multiplication yielding an int result. (It overflows, which invokes
undefined behavior, which most likely shows up as discarding the
high-order bits.) That int result then becomes the right operand of
the "/" operator. The left operand of the "/" operator is (long
long)8000000000 00, which is of type long long, so the right operand is
promoted to long long -- but that promotion (to 64 bits) is done
*after* the 32-bit multiplication.

Since the overflow invokes undefined behavior, I suppose a
sufficiently clever compiler could let the context affect the
evaluation of (5000000*num), so the whole expression yields a
mathematically correct result. But such cleverness doesn't really do
you any favors, it merely masks your error.

(There are languages in which the context of an expression affects its
evaluation. C is not such a language.)

You might prefer to use a suffix on the integer constants rather than
casting them to long long:

long long int reg=80000000000 0LL/(5000000LL*num) ;

On the other hand, the cast uses the type name explicitly, so it might
be considered clearer.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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.

[Keith Thompson]

Chris Croughton <ch***@keristor .net> writes:

On Sun, 02 Jan 2005 17:26:27 +0100, jacob navia
<ja***@jacob.re mcomp.fr> wrote:

[...]

Maybe there are compilers that clever, but I would not rely
on it, and would add the cast.

It would not be 'clever', it would be against the standard.

[...]

As I mentioned in another thread, it wouldn't be against the standard
if it affected the visible behavior of the program only when it
invokes undefined behavior. But such "cleverness " would not be a good
idea, since it would tend to mask errors.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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.

[Keith Thompson]

Keith Thompson <ks***@mib.or g> writes:

Chris Croughton <ch***@keristor .net> writes:

On Sun, 02 Jan 2005 17:26:27 +0100, jacob navia
<ja***@jacob.re mcomp.fr> wrote:

[...]

Maybe there are compilers that clever, but I would not rely
on it, and would add the cast.

It would not be 'clever', it would be against the standard.

[...]

As I mentioned in another thread, it wouldn't be against the standard
if it affected the visible behavior of the program only when it
invokes undefined behavior. But such "cleverness " would not be a good
idea, since it would tend to mask errors.

Sorry, I meant to say "As I mentioned elsewhere in this thread ...".

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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.

[Jack Klein]

On Sun, 02 Jan 2005 23:03:44 GMT, Keith Thompson <ks***@mib.or g> wrote
in comp.lang.c:

Chris Croughton <ch***@keristor .net> writes:

On Sun, 02 Jan 2005 17:26:27 +0100, jacob navia
<ja***@jacob.re mcomp.fr> wrote:

[...]

Maybe there are compilers that clever, but I would not rely
on it, and would add the cast.

It would not be 'clever', it would be against the standard.

[...]

As I mentioned in another thread, it wouldn't be against the standard
if it affected the visible behavior of the program only when it
invokes undefined behavior. But such "cleverness " would not be a good
idea, since it would tend to mask errors.

True. But if either of the operands in the calculation of the
denominator were unsigned, such 'early promotion' would be
non-conforming.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Neo]

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes:

I'm using gcc-3.4.3 on a linux pc. The ints and long ints are 32 bits
and long long ints are 64 bits.

When i have:

int num=9600;
long long int reg=(long long)8000000000 00/(5000000*num);

the denominator overflows and gives an incorrect answer: reg=1059

With an extra cast:

long long int reg=(long long)8000000000 00/((long long)5000000*nu m);

i get: reg=16

If the numerator is a long long int, should the denominator be
automatically promoted to a long long int?
The evaluation of an expression is not affected by the context in
which it appears. Think of expressions, including their
subexpressions, as being evaluated bottom-up, not top-down.

The right operand of the "/" operator is:

(5000000*num)

Each operand of the "*" is of type int, so it's an int-by-int
multiplication yielding an int result. (It overflows, which invokes
undefined behavior, which most likely shows up as discarding the
high-order bits.) That int result then becomes the right operand of
the "/" operator. The left operand of the "/" operator is (long
long)8000000000 00, which is of type long long, so the right operand is
promoted to long long -- but that promotion (to 64 bits) is done
*after* the 32-bit multiplication.

Since the overflow invokes undefined behavior, I suppose a
sufficiently clever compiler could let the context affect the
evaluation of (5000000*num), so the whole expression yields a
mathematically correct result. But such cleverness doesn't really do
you any favors, it merely masks your error.

(There are languages in which the context of an expression affects its
evaluation. C is not such a language.)

You might prefer to use a suffix on the integer constants rather than
casting them to long long:

long long int reg=80000000000 0LL/(5000000LL*num) ;

Hi Keith,

I used the following form :

int num = 9600;
long long int i = (long long)8000000000 00/(5000000LL * num);
printf("%ld\n", i);

on my Win XP machine (gcc 3.3.1) gcc flash out the following warning :
longlong.c: In function `main':
longlong.c:7: warning: integer constant is too large for "long" type
output : 16

and to more surprise when compiling the same code on Solaris Workstation
with gcc 3.3 warning was the same as above but the result :
output : 0

WHY IT IS SO??????

Thanks n Regards
-Neo

On the other hand, the cast uses the type name explicitly, so it might
be considered clearer.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org
<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.

[Michael Mair]

Neo wrote:

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes:

I'm using gcc-3.4.3 on a linux pc. The ints and long ints are 32 bits
and long long ints are 64 bits.

When i have:

int num=9600;
long long int reg=(long long)8000000000 00/(5000000*num);

the denominator overflows and gives an incorrect answer: reg=1059

With an extra cast:

long long int reg=(long long)8000000000 00/((long long)5000000*nu m);

i get: reg=16

If the numerator is a long long int, should the denominator be
automaticall y promoted to a long long int?

The evaluation of an expression is not affected by the context in
which it appears. Think of expressions, including their
subexpression s, as being evaluated bottom-up, not top-down.

The right operand of the "/" operator is:

(5000000*num)

Each operand of the "*" is of type int, so it's an int-by-int
multiplicatio n yielding an int result. (It overflows, which invokes
undefined behavior, which most likely shows up as discarding the
high-order bits.) That int result then becomes the right operand of
the "/" operator. The left operand of the "/" operator is (long
long)80000000 0000, which is of type long long, so the right operand is
promoted to long long -- but that promotion (to 64 bits) is done
*after* the 32-bit multiplication.

Since the overflow invokes undefined behavior, I suppose a
sufficientl y clever compiler could let the context affect the
evaluation of (5000000*num), so the whole expression yields a
mathematicall y correct result. But such cleverness doesn't really do
you any favors, it merely masks your error.

(There are languages in which the context of an expression affects its
evaluation. C is not such a language.)

You might prefer to use a suffix on the integer constants rather than
casting them to long long:

long long int reg=80000000000 0LL/(5000000LL*num) ;

Hi Keith,

I used the following form :

int num = 9600;
long long int i = (long long)8000000000 00/(5000000LL * num);
printf("%ld\n", i);

on my Win XP machine (gcc 3.3.1) gcc flash out the following warning :
longlong.c: In function `main':
longlong.c:7: warning: integer constant is too large for "long" type
output : 16

and to more surprise when compiling the same code on Solaris Workstation
with gcc 3.3 warning was the same as above but the result :
output : 0

WHY IT IS SO??????

RTFmanpage (printf):

The length modifier l specifies _long_, not _long_long_.
If you want to print a long long, use ll:
printf("%lld\n" , i);

Depending on the byte representation of the number in memory, we may
well arrive at 16 (korrekt) or 0, if erroneously reading only a part
of the bytes belonging to the argument.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.