Longs, ints and printf (ansi-C)

[elendil]

Hi...

I have just finished my little hexadecimal to decimal tool, and again stumbled on the stupid 32 bit barrier of integer values...

A few questions:

a) ints and longs are usually the same these days, aren't they? The ansi-C reference I'm looking at claims ints are 16 bit and longs are 32 bits, but ints are 32 as well these days?

b) why won't printf print longs and is there any way around that (besides casting to integer)?

c) Why does an unsigned integer overflow with values such as FFFF FFAA?

d) Working with longs I appear to get no overflows no matter how big a number I use, at least the if(number < 0) is never true for longs. Why is that?

d) Work-arounds?

Thanks,

Sincerely,

-Kenneth Straarup.

[Kronos]

a) nope, "int" has allways been CPU-specific, and was 16bit on 16bit CPUs.

b) dunno, I can printf (U)LONG, what compiler are you useing ?

c) ? it seems that you/the compiler is interpreting an unsigned
int as an signed int. Have a real close look at your sources,
or post them here.

d) you mean 1500000000+1000000000 doesn't end up negative ?
Probraly the CPU truncating everything that would go beond
0xafffffff.

[Piru]

a) ints and longs are usually the same these days, aren't they? The ansi-C reference I'm looking at claims ints are 16 bit and longs are 32 bits, but ints are 32 as well these days?

Your reference is sh1te then. There are no strict fixed sizes, but certain rules. For example:
8 bits <= char <= short <= int <= long
16 bits <= short <= int <= long
32 bits <= long

If you must know the limits for specific types on the particular implementation, see .

b) why won't printf print longs and is there any way around that (besides casting to integer)?

%ld prints long.

c) Why does an unsigned integer overflow with values such as FFFF FFAA?

It does overflow if you add something to that value so that the result would be > FFFFFFFF.

d) Working with longs I appear to get no overflows no matter how big a number I use, at least the if(number < 0) is never true for longs. Why is that?

Because you use unsigned long? With unsigned type (number < 0) is never true.

[elendil]

Hi,

I'm using gcc (3.3 for osX, I think).

It seems some of my problems are related to the fact that gcc ignores my pretty 'unsigned' letters in front of the variables. At least I have overflows at less than 32 bits, and I can put negative values into them as well.
Any suggestions?

%ld worked for printing longs, btw, so thanks.

Sincerely,

-Kenneth Straarup.

[Thomas]

The "unsigned" is mainly used when moving small variables into bigger oned. E.g. moving an unsinged short into a long results in a range from 0 to 65535 while moving a signed short into a long has a range from -32768 to 32767. It is totally ignored for add and subtract operations because the binary result is always the same.

When outputting unsigned values with printf you have to use the correct format specification (%u instead of %d) because there is no checking if you do it correct. You can even output a long with %s which usually leads to a crash. So if you work with unsigned longs you have to use %lu. If you use %ld you will get negative numbers for everything above 2^32.

Generelly you can use this table:

signed short -> %hd
unsigned short -> %hu
signed int -> %d
unsigned int -> %u
signed long -> %ld
unsigned long -> %lu

Because some compilers always put long (32bit) values onto the stack (like most Amiga compilers), you might always have to use %ld/%lu for shorts, too. %d is interpreted compiler-specific and should only be used with int which is compiler-specific, too.

Bye,
Thomas

[elendil]

Hi,

Thanks for that clarification. I'll go try that right away...or when I'm allowed to play with the gf's ibook again - my own laptop is at the repair shop atm, sniff sniff

Sincerely,

-Kenneth Straarup.

[CodeSmith]

It seems some of my problems are related to the fact that gcc ignores my pretty 'unsigned' letters in front of the variables. At least I have overflows at less than 32 bits, and I can put negative values into them as well.

That's an easy problem to fix.  The thing is, integer constants in C (or C++) are assumed by the compiler to be of type int (ie signed).  So when you say

unsigned long x = 0xffffffaa;

the compiler takes that as meaning

unsigned long x = (int) 0xffffffaa;

So the solution is to tell the compiler that your integer constant is an unsigned long instead of an int.  You do that like this:

unsigned long x = 0xffffffaaUL;

The UL at the end tells the compiler it's an Unsigned Long instead of an int.  You can also use U or L on their own (eg 0L or 45U), but most of the time it doesn't make a difference - only when you're dealing with large unsigned constants like 0xffffffaa.

[melott]

You might consider joining this group of
Amiga 'C' programers.
The mentor is 'VERY' good.

amiga_bcg@yahoogroups.com

or send an empty EMail to

amiga_bcg-subscribe@yahoogroups.com