Re: is order urgent doubt

new to c wrote:
Keith Thompson wrote:

new to c <non@xxxxxxxxxxxx> writes:
Bartc wrote:
"new to c" <non@xxxxxxxxxxxx> wrote in message news:6468955.gypaU67uLZ@xxxxxxxxxxxxxxxx

I write big international program and need double integer. Why size is
different when other order?
Try: long long int

If you're lucky, this will have size 8.

Problem equal.
You mean "the same problem".

int i;
i = sizeof(long long int);
printf("%i", i);

i = sizeof(long int long);
printf("%i", i);

i = sizeof(int long long);
printf("%i", i);

First code warn nothing and print 8.

Second code warn "multiple use of 'long'" and print 4.

Third code warm "multiple use of 'longlong'" and print 8.

Why is different number? Is order urgent?
You mean "important" or "significant", not "urgent".

Assuming the code you posted is the code you actually compiled and
ran, it appears that your compiler is buggy. What compiler are you
using?

Please post a small complete program that exhibits the problem.
Copy-and-paste the entire exact program; don't re-type it or summarize
it. Show us the compiler's warnings and the program's output
(copy-and-paste them as well).

Change each "%i" to "%i\n" (or "%d\n", which is equivalent but more
common).

Not all compilers support "long long", but most do (the feature was
added in C99, but a lot of pre-C99 compilers support it as an
extension).

All three chunks of code are exactly equivalent. For an integer type,
the order of the keywords is not significant; all of "long long int",
"long int long", and "int long long" mean exactly the same thing. If
your compiler is treating them differently, then there's a bug in your
compiler. (I think we've already told you this.)

As a matter of programming style, messing around with the order of the
keywords isn't a good idea. A properly working compiler won't care,
but using an order other than the usual one will just make your code
(slightly) harder to read, with no real benefit. (It's been argued
that using, for example, "long unsigned" rather than "unsigned long"
helps to remind you to use "%lu" rather than "%ul" for printf; I don't
find that argument convincing.)

Also, if you use the more common orderings, it's likely you can avoid
triggering your compiler's bugs (though I'd recommend finding a
compiler that works properly).

I use wedit IDE.

I write this code :

#include <stdio.h>
int main(void)
{
int i;

i = sizeof(long int);
printf("sizeof(long int): %d\n", i);

i = sizeof(int long);
printf("sizeof(int long): %d\n", i);

i = sizeof(double int);
printf("sizeof(double int): %d\n", i);

i = sizeof(int double);
printf("sizeof(int double): %d\n", i);

i = sizeof(long long int);
printf("sizeof(long long int): %d\n", i);

i = sizeof(long int long);
printf("sizeof(long int long): %d\n", i);

i = sizeof(int long long);
printf("sizeof(int long long): %d\n", i);

return 0;
}

Compiler warn

Warning c:\New_Folder\Test.c: 3 old-style definition for 'main'
Warning c:\New_Folder\Test.c: 3 missing prototype for 'main'
Warning c:\New_Folder\Test.c: 12 multiple use of 'int'
Warning c:\New_Folder\Test.c: 15 multiple use of 'double'
Warning c:\New_Folder\Test.c: 21 multiple use of 'long'
Warning c:\New_Folder\Test.c: 24 multiple use of 'longlong'
Compilation + link time 24.2 sec, Return code: 0

Code print

sizeof(long int): 4
sizeof(int long): 4
sizeof(double int): 4
sizeof(int double): 8
sizeof(long long int): 8
sizeof(long int long): 4
sizeof(int long long): 8


Hi.

I am the author of lcc-win. I have changed the warning messages to a
clearer one. Now your program produces the following warnings:
Warning td.c: 12 multiple types in a declaration. Last will be used: 'int'
Warning td.c: 15 multiple types in a declaration. Last will be used: 'double'
Warning td.c: 21 multiple types in a declaration. Last will be used: 'long'
Warning td.c: 24 multiple types in a declaration. Last will be used: 'longlong'

Maybe this will clarify what lcc-win is doing.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
.

Relevant Pages

  • Re: Parameter Name Warning?
    ... the names on the declarations do not matter, it should perhaps give a warning regarding different names being used. ... > there is more to those names than just what the compiler does with them. ... > You know only what you get in the header. ... >>> int main ...
    (microsoft.public.vc.language)
  • Re: is order urgent doubt
    ... Which *compiler* are you using? ... layout of the warning messages.) ... i = sizeof(long int); ... about the code in the editor vs. the code in the source file. ...
    (comp.lang.c)
  • Re: Whats the deal with size_t?
    ... ES> allowed to emit diagnostics that C doesn't require. ... in warning about a signed to unsigned conversion. ... a size_t to an int it is quite justified in warning about the reverse, ... The compiler is also quite justified in warning if you use a signed ...
    (comp.lang.c)
  • Re: Compendiums of compiler warning/error messages mapped to actual code problems?
    ... The general problem is of course that the compiler messages must be short, and that tends to make them so cryptic that it isn't always immediately obvious what the problem is. ... int this; ... Warning twarn.c: ...
    (comp.lang.c)
  • Re: matrix stuff (solving b = A*x) --> using numerical recipes
    ... but then I removed it since I couldn't see any compiler warnings/errors without stdio.h). ... turn the warning level up to the maximum ... void banmul(float **a, unsigned long n, int left, int right, float x, float b); ...
    (comp.lang.c)