Solved

# sizeof (int)

Posted on 2003-11-25
410 Views
When size of int is machine dependent, why not to use short and long data types instead of int?
0
Question by:vivekGupta
• 4
• 4
• 2
• +3

LVL 45

Accepted Solution

sunnycoder earned 20 total points
Hi vivekGupta,

your question does not make much sense to me!! size of any builtin data type will be machine dependent including short and long ... some machines have 8 byte long and others have 4 byte long.

Cheers!
Sunny:o)
0

Author Comment

According to ANSI C, size of long is fixed at four and size of short is fixed at 2.
Size of int is variable. It may  be 2 or 4 depending on he machine
0

LVL 45

Expert Comment

can you tell me which section of the standard says so ... I cant seem to locate it
0

LVL 45

Expert Comment

Hi vivekGupta,

The "general rule" concerning the sizes of short, int, and long simply says that a short cannot be longer than an int and an int cannot by longer than a long.  (By implication, a short can therefore not be longer than a long either.)

I can remember working on a system in about 1988 that had a 64-bit int. :)  (Pretty rare, even today.)

But back to your question, the short, int, and long data types go back to the days when memory was very limited.  Most integer calculcations were performed on ints.  When large numbers were expected, longs were used.  short ints were quite common for index values.

On today's much larger memory systems it's not necessary to use variables that are "just big enough" so shorts are seldom used.  Where you're most likely to see short, int, long, and (sometimes) long long definitions is in data structures.

Kent
0

Expert Comment

size of built in variable also depends on the compiler memory model... as wel as machine
as sunny coder states the size of int varies from 2 byte to 4 byte.. atleast what i have seen
0

Expert Comment

This whole thing seems like a pretty dumb argument ... The 2/4 byte rule though it isn't hard and fixed, is a historical rule of thumb, where anything else (and there were) was consicered an exception.  Of course nowadays there are more excptions than rules, so the whole concept is obsolete.

The original question is what are 'int's good for if you can't rely on the size, and I pretty much agree.  If you want a long, use a long, and if you want a short, use a short.  Also, its a good practice to be explicit if its signed or unsigned, etc.  I find this minimizes the supprises when you port from one platform to another.  I myself only use integers for type compatability (if you call a function which takes int args, or returns an int, then use an int accordingly) and for variables which traditionally are 'int's such as 'for' loop counters.

For my money though, in the context of the original question, you're right; You really don't need 'int's.  And from experience, if you are dealing with magnitudes where it matters, declaring everything as an explicit long or short is a good idea.

Eric-K
0

LVL 45

Expert Comment

Hi Eric-K

I have to disagree with you in that there is no 2/4 byte rule that is a "historical rule of thumb".  C goes back to the days of 8-bit processors and has evolved as the processors underneath it have.  'int' type variables are historically the "default" computation entity on the host system.  Most systems today have 32-bit processors and 'int' variables on these systems are 32 bits.  486 machines had a 16-bit processors and 'int' variables on them were 16 bits.  When the 64-bit systems become widely available we can expect that an 'int' will be 64 bits.

Unless, of course, I missed your meaning,
Kent
0

Expert Comment

Kent,

I guess the word "historical" has to do with how old you are.  From the way you speak, I suspect you're a bit younger than I am.

C language goes back a good deal before the 8-bit processors that I think you're referring to.  If you reckon from that point in time, then you're right.  But going back further, the 2/4 rule held pretty well for a long time.  It was when the 8-bit computers started comming out, that the rule started to fall apart ... so its not valid any more, maybe it hasn't been for a long time ... its "historical".

-Eric
0

LVL 45

Expert Comment

Hi Eric,

I that you for the returned illusion of youth.  In fact, the receding hairline that has my forehead more resembling a five or even six-head coupled with the very salty beard makes the illusion ever more fleeting.  :)

I've been around a while.  Attending college in the early/mid 70s (though I was never much of a student).  In fact, I started working with unix/C back in '82 or so, but it was on a 68000 based system.  I shunned PCs for a long time and didn't get serious into that paradigm until the early 90s.

Kent
0

Expert Comment

Hi Kent,

Nice to meet you ...

We all shunned the early PCs, at least all us legitimate guys of the period ...
Heck, they couldn't even get the size of a 'long' right! (he he).

I predate you by a few years, but not much ... started in Fortran on IBM 360, moved up to Macro Assembly on PDP-10, then PDP-11's, then C on PDP-11's
and 3B20's (Bell Labs box, never saw it outside AT&T) ... Moved over to Unix Labs where I had occasion to use C on virtually every platform that supported Unix.  Now its mostly C++ and Java ...

BTW - Until '94*, a huge amount of core code in the Unix OS depended on the fact that a long was 4 bytes, and that a short was 2 bytes.  You know, things like knowing what the packing was gong to be in a structure, and hard coding offsets, or masking a long with a hard coded constant to test bit 30 of the word ...  Dirty yes, but stuff like that was done.  You couldn't trust an 'int', but if you used an explicit 'long' or 'short' that was considered safe.

(*) 1994 was when USL was bought out by Novell (and later resold to HP) ...
HP subsequently did a major overhaul of the code.

-Cheers, Eric
0

LVL 45

Expert Comment

Hi Eric,

Nice meeting you, too.

I started in FORTRAN on a CDC 6600 back in '72.  The assembler, BASIC, COBOL, and before you knew it I had a dozen languages on my resume.  (Most of which the world has never heard of.  Of course, with your DEC background you might actually know a little DIBOL.)

Long about '85 I was working on a CYBER 205.  Our staff was supposed to develop unix/C for the machine, but CDC management being CDC management, we sat around doing little to nothing for 18 months while the customer pretended to be in charge.  :)  In '88 I moved into their Lottery Division and can still remember a guy from Scientific Games installing their proprietary algorithms on the machine.  He brought their C source and produced object code for us and just couldn't get over the fact that an int was 64 bits.

Nearly all of the C code that I've produced is almost universally transportable.  When the size of an int matters, I define it as an Int8, UInt8, Int16, UInt16, etc in storage.h.  When the source code moves, I just drop in the storage.h with the typedefs for that system and the code runs just fine.  All the tricks that we accumulate over the years..  It's too bad that we weren't this smart when we were building operating systems, huh?

Kent
0

Expert Comment

Well Kent, I guess we've both been around the block a few times ...

vivekGupta, are you still there?

-Eric
0

LVL 15

Expert Comment

I think sunnycoder's first comment answered the question.
0

## Featured Post

### Suggested Solutions

Have you thought about creating an iPhone application (app), but didn't even know where to get started? Here's how: ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Important pre-programming comments: I’ve never tri…
An Outlet in Cocoa is a persistent reference to a GUI control; it connects a property (a variable) to a control.  For example, it is common to create an Outlet for the text field GUI control and change the text that appears in this field via that Ou…
The goal of this video is to provide viewers with basic examples to understand recursion in the C programming language.
The goal of this video is to provide viewers with basic examples to understand and use while-loops in the C programming language.