i'm trying to compile this small program:

int main(void) {

        unsigned long int max;

        max = 4000000000;

        return 0;

limits.c: In function `main':
limits.c:5: warning: this decimal constant is unsigned only in ISO C90

i read both here
(http://www-ccs.ucsd.edu/c/express.html#decimal%20integer%20constant)
and on my book (Kelley-Pohl), that if i have a decimal integer constant
with no suffix, then the compiler will choose among the following
ordered list:

        1) int
        2) long int
        3) unsigned long int

the first one which is able to represent that constant. since on my
system both int and long int are 4 bytes sized, then i would expect
4000000000 is unsigned long int. since i am assigning an unsigned long
int constant to an unsigned long int variable, i don't see why i should
get that warning.

i know two ways to avoid the warning:

        1) specifing 4000000000UL instead of 4000000000
        2) using 0xEE6B2800 instead of 4000000000

but i'd like to understand why 4000000000 is not ok.

note that i'd like to write only ANSI/ISO C compatible programs
(C89/C90), no traditional C or C99 ones (after having learned C89, i
will switch to C99 if i'll have time).

i am using gcc version 3.4.4 on a gentoo linux system.
parameters: gcc -x c -ansi -pedantic -Wall -Wextra (i get that warning
also with no parameters at all)

also, i found this parameter:

-Wtraditional

[...]

*   The ISO type of an integer constant has a different width or
signedness from its traditional type.  This warning is only issued if
the base of the constant is ten.  I.e. hexadecimal or octal values,
which typically represent bit patterns, are not warned about.

[...]

fctk wrote On 03/29/06 10:26,:

    For C90, the rule is as you stated: the type will be
the first of int, long int, or unsigned long int that
can accommodate the value, and on your system this comes
down to unsigned long int.

    For C99, the type will be the first of int, long int,
or long long int that can accommodate the value, which
for your system would turn out to be long long int.

    Recommendation: If you want an unsigned long, tack
on a "UL" suffix.

  -- signed int
  -- signed long
  -- signed long long

...in which it fits.  Under C99, an unadorned decimal constant never
becomes an unsigned type.

So the diagnostic is telling you that the constant is interpreted
differently depending on which version of ISO C is being conformed to.
If the compiler is invoked in C90 conforming mode, the type of the
constant is "unsigned long", but in C99 conforming mode, the type is
"signed long long".  If the destination was a signed type, the actual
value after initialization might be different between the two
versions.  And this code could break on other platforms.

Also consult your compiler documentation.  There is some way to tell
gcc which version of the C standard you want it to conform to.

i tried to specify -std=iso9899:1990 (C89/C90) in the gcc parameters
list, but i get that warning again.

i still wonder. i don't mind about C99, i'd like gcc not to be aware of
its existence. when C89/C90 was made (1989/1990) C99 didn't existed, so
why telling me my program can produce different results if compiled with
C99 standard? C99 doesn't exist...

Note that, in principle, a compiler can warn you about everything
it likes to ("Your code contains 42 'i's -- that is a bad omen on
days like this one").
Maybe, in gnu.gcc.help someone can tell you how to achieve that
(or maybe you find something in the gcc documentation yourself).

However, if you go this way, then consider at least protecting
these others (or maybe even yourself) from errors:
  #if __STDC_VERSION__ >= 199901L
  #  error My code does not work for C99 or newer standards
  #endif

If you are maintaining old code and if this warning comes up at
hundreds of different places, switching off or filtering this
warning and putting the above in one source file may be a
sensible way to go. The decision should be clearly documented
somewhere.
If you are writing new code, then the warning is justified and
removing its cause as often as it comes up is just sensible --
why leave unnecessary and potentially dangerous degrees of
freedom in your code if you can say exactly what you mean?