• C

sizeof (int)

When size of int is machine dependent, why not to use short and long data types instead of int?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
vivekGuptaAuthor Commented:
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
can you tell me which section of the standard says so ... I cant seem to locate it
Cyber security certifications or degree?

Cyber security is in demand—big-time. So what do you need to build a career in this lucrative field? Is a degree a must-have, or are industry-leading certifications more sought-after? Is it possible to break into cybersecurity without a bachelor’s or master’s degree in the field?

Kent OlsenDBACommented:

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.

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
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.

Kent OlsenDBACommented:
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,


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".

Kent OlsenDBACommented:

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.


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
Kent OlsenDBACommented:
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?


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

vivekGupta, are you still there?

I think sunnycoder's first comment answered the question.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.