which tutorial to use?

[santosh]

Then why not provide a 32-bit int and a 64-bit long?

That's what is commonly done on 64 bit systems, Microsoft being an
exception. The point that user923005 made is that when C was created
the type int was meant to map to the machine's natural integer size,
which under most 64 bit systems is of course 64 bits. But if int is
made 64 bits then we have to sacrifice either a 16 bit or 32 bit type,
mostly the former. But a 32 bit short just feels weird! Also if int is
64 bits what is long supposed to be? And what about long long?

That's why I agree with Jacob that even under 64 bit systems int is best
left at 32 bits, and long made 64 bits.

 

[jacob navia]

That's what is commonly done on 64 bit systems, Microsoft being an
exception. The point that user923005 made is that when C was created
the type int was meant to map to the machine's natural integer size,
which under most 64 bit systems is of course 64 bits. But if int is
made 64 bits then we have to sacrifice either a 16 bit or 32 bit type,
mostly the former. But a 32 bit short just feels weird! Also if int is
64 bits what is long supposed to be? And what about long long?

That's why I agree with Jacob that even under 64 bit systems int is best
left at 32 bits, and long made 64 bits.

lcc-win under linux sets long 64 bits (equal to long long)
lcc-win under windows sets long 32 bits, long long 64, and
int128 at... yes! you guessed it.

This things are set by the OS ABI, not by the compiler

 

[user923005]

On a 64 bit CPU, int serves nicely as long long (if the compiler is
constructed sensibly).

[snip]

NO!!

If the compiler is sensible it will keep int 32 bits, as
gcc and microsoft decided (and with reason!)

The problem is that if you put int to 64 bits you have a BLOAT
of the size of all structures, and your program slows down
because it has to move TWICE as much data that a 32 bit program!

It's a trade-off because the natural alignment of a 64 bit system is
on 64 bit boundaries and so the loading of the smaller registers can
be slower.
Of course, even with int==64 bits, you will still have all the fast
and exact types defined in stdint.h and so you will lose nothing on
performance if you use these types.

In all 64 bit compilers I know, int is still 32 bits.

Yet there are some with 64 bit int.
NEC SX-4 has a mode where sizeof(int)==8
Cray and ETA have also both used ILP64 model.
HAL Computer's SPARC64 uses 64 bit int for C.

On the other hand, there is probably a lot of badly written code that
assumes ints are 32 bits and will break if they are transformed into
64 bit quantities.

 

[Ioannis Vranos]

That's what is commonly done on 64 bit systems, Microsoft being an
exception.

OK then, we can agree in an approach like this, and not add long long.

short being 16-bits, int being 32-bits and long being 64-bits. Why do we
need long long? For having *two types* being equivalent (short and int
being 16-bits) so as to need long long?

The point that user923005 made is that when C was created
the type int was meant to map to the machine's natural integer size,
which under most 64 bit systems is of course 64 bits. But if int is
made 64 bits then we have to sacrifice either a 16 bit or 32 bit type,
mostly the former. But a 32 bit short just feels weird! Also if int is
64 bits what is long supposed to be? And what about long long?

That's why I agree with Jacob that even under 64 bit systems int is best
left at 32 bits, and long made 64 bits.

Regarding the machine's natural word type, I think int should be 64-bits
on a 64-bit system. The space issue is short-sighted, space facilities
increase over time, consider the space facilities of OSes like 32-bit
Windows/Linux era vs DOS 3.30 era.

 

[Ioannis Vranos]

On the other hand, there is probably a lot of badly written code that
assumes ints are 32 bits and will break if they are transformed into
64 bit quantities.

This isn't an excuse to add types for people who do not know programming.

 

[santosh]

OK then, we can agree in an approach like this, and not add long long.

short being 16-bits, int being 32-bits and long being 64-bits. Why do
we need long long? For having *two types* being equivalent (short and
int being 16-bits) so as to need long long?

Not under Windows, where long is fixed to 32 bits.

Regarding the machine's natural word type, I think int should be
64-bits on a 64-bit system. The space issue is short-sighted, space
facilities increase over time, consider the space facilities of OSes
like 32-bit Windows/Linux era vs DOS 3.30 era.

Asking your customer to double their memory to accommodate your programs
is wasteful. As I said, most programs don't *need* 64 bits for most of
their integer calculations. A 32 bit type is still ideal for many
tasks, so it's out of question to drop it. And between short or int
being 32 bits I much prefer the latter case. So that leaves long with
64 bits and long long above that, presumably with 128 bits.

 

[Ioannis Vranos]

OK then, we can agree in an approach like this, and not add long long.

short being 16-bits, int being 32-bits and long being 64-bits. Why do we
need long long? For having *two types* being equivalent (short and int
being 16-bits) so as to need long long?





Regarding the machine's natural word type, I think int should be 64-bits
on a 64-bit system. The space issue is short-sighted, space facilities
increase over time, consider the space facilities of OSes like 32-bit
Windows/Linux era vs DOS 3.30 era.

Regarding the loss of a specific 16-bit or 32-bit value range on an 64
bit system, I can't find any reason why missing the 16-bit range would
be bad.

 

[santosh]

Regarding the loss of a specific 16-bit or 32-bit value range on an 64
bit system, I can't find any reason why missing the 16-bit range would
be bad.

ITYM a 16 bit type.

WRT what you say, neither can I, but I have been told that a lot of
multimedia programming involves processing 16 bit values, though I
would think that for this corner case int16_t could be used.

But this is unnecessary if short is 16 bits. That's unlikely to change.
And in most compilers int is 32 bits.

 

[Ioannis Vranos]

Not under Windows, where long is fixed to 32 bits.


Asking your customer to double their memory to accommodate your programs
is wasteful. As I said, most programs don't *need* 64 bits for most of
their integer calculations. A 32 bit type is still ideal for many
tasks, so it's out of question to drop it. And between short or int
being 32 bits I much prefer the latter case. So that leaves long with
64 bits and long long above that, presumably with 128 bits.

I consider long long one of the bad features of C99. I am talking about
C95 facilities:

Isn't the following sufficient for a 64-bit machine?

short 16-bits, int 32-bits, long 64-bits

 

[Ian Collins]

Regarding the loss of a specific 16-bit or 32-bit value range on an 64
bit system, I can't find any reason why missing the 16-bit range would
be bad.

16 bit quantities are remarkably common.

 

[Ian Collins]

santosh wrote:

Regarding the machine's natural word type, I think int should be 64-bits
on a 64-bit system. The space issue is short-sighted, space facilities
increase over time, consider the space facilities of OSes like 32-bit
Windows/Linux era vs DOS 3.30 era.

See

http://www.unix.org/version2/whatsnew/lp64_wp.html

and learn how the real world works.

 

[Ioannis Vranos]

ITYM a 16 bit type.

WRT what you say, neither can I, but I have been told that a lot of
multimedia programming involves processing 16 bit values, though I
would think that for this corner case int16_t could be used.

But this is unnecessary if short is 16 bits. That's unlikely to change.
And in most compilers int is 32 bits.

Anyway, wouldn't the following be sufficient for a 64-bit system:

short being 16-bits, int being 32-bits and long being 64-bits

 

[Ioannis Vranos]

See

http://www.unix.org/version2/whatsnew/lp64_wp.html

and learn how the real world works.

Can you pinpoint your point in the URL above?

 

[santosh]

Ioannis Vranos wrote:

I consider long long one of the bad features of C99.

If that is so, then by extension one can say that even the presence of
short and long are "bad" features (Hi Malcolm!). C's type system is
less than elegant after C99, but I suppose the flexibility was needed
by it's programming community. In particular, the exact width types are
often very useful, as is long, since in a portable C program you cannot
assume that you can form values over 65535 with int.

I am talking about C95 facilities:

Isn't the following sufficient for a 64-bit machine?

short 16-bits, int 32-bits, long 64-bits

Yes. As I said, this model is a common one, except in Windows land. See
the link that Ian Collins provided in reply to you elsethread.

 

[CBFalconer]

.... snip ...

Actually the point he makes is a sensible one. We don't need long
long to be a minimum of 64 bits but a minimum of 128 bits. Ideally
short would be 16 bits, int 32 and long 64. However because of
various 16 bit systems and the design decision made by Microsoft
we are stuck with 16/32 bit int and 32 bit long.

No, you are not stuck. <limits.h> specifies the various sizes.
Any implementor can make them whatever he likes, provided he meets
the minimum sizes.

 

[user923005]

See

http://www.unix.org/version2/whatsnew/lp64_wp.html

and learn how the real world works.

The same arguments could have been made for 16 bit ints changing into
32 bit ints 'back in the day'.

Aren't you glad that they did not take that nonsense stance back then?

Ten years from now, 32 bit ints are going to look very foolish.
Especially when stdint.h gives you 32 bit sizes if you want them.

IMO-YMMV.

I must admit you are right though. The way the real world works *is*
broken.

P.S.
From K&R2, p36:
"The intent is that short and long should provide different lengths of
integers where practical; int will normally be the natural size for a
particular machine. short is often 16 bits long, and int either 16 or
32 bits. Each compiler is free to choose appropriate sizes for its own
hardware, subject only to the the restriction that shorts and ints are
at least 16 bits, longs are at least 32 bits, and short is no longer
than int, which is no longer than long."

 

[santosh]

Can you pinpoint your point in the URL above?

The point is that most 64 bit systems use the so called LP64 model,
i.e., int is 32 bits, long and pointer types are 64 bits. That paper
gives the rationale for that decision and the study behind it.

It's a counterargument for ILP64 enthusiasts.

 

[Ioannis Vranos]

Ioannis Vranos wrote:



If that is so, then by extension one can say that even the presence of
short and long are "bad" features (Hi Malcolm!). C's type system is
less than elegant after C99, but I suppose the flexibility was needed
by it's programming community. In particular, the exact width types are
often very useful, as is long, since in a portable C program you cannot
assume that you can form values over 65535 with int.

I am not sure what you are saying here. One can find the maximum/minimum
values of his system types by checking limits.h and float.h

Yes. As I said, this model is a common one, except in Windows land. See
the link that Ian Collins provided in reply to you elsethread.

So why do we need long long?

 

[user923005]

See

http://www.unix.org/version2/whatsnew/lp64_wp.html

and learn how the real world works.

A quote from that link:
"The world is currently dominated by 32-bit computers, a situation
that is likely to exist for the foreseeable future."

Ummm.... When was *that* written?

 

[Ioannis Vranos]

The point is that most 64 bit systems use the so called LP64 model,
i.e., int is 32 bits, long and pointer types are 64 bits. That paper
gives the rationale for that decision and the study behind it.

It's a counterargument for ILP64 enthusiasts.

OK, I think I agree with the "LP64" list:

Datatype LP64
char 8
short 16
_int32
int 32
long 64
long long
pointer 64


I think the above supports what I say.