Home > Archive > C > August 2004 > Re: Small C "Puzzle"
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Small C "Puzzle"
|
|
|
|
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnwtzj4kin.fsf@nuthaus.mib.org...
> g_satyamohanraju@yahoo.co.in (Raju) writes:
> [...]
>
> The size of "int" is whatever the compiler implementer decides it
> should be. On the IA-64 (also known as Itanium), int is 32 bits, and
> pointers are 64 bits. More precisely, these are the sizes chosen by
> the compilers I'm familiar with on IA-64 systems (gcc and Intel's
> compiler under Linux). Note that there's a strong motivation for
> different compilers on the same system to be compatible with each
> other.
>
> Since the IA-64 is a 64-bit system, it's natural to assume that int
> should be 64 bits, but that would actually cause some problems.
> Currently, the types of the predefined integer types are:
>
> char 8 bits
> short 16 bits
> int 32 bits
> long 64 bits
> long long 64 bits
>
> If int were 64 bits, short would be either 16 or 32 bits, leaving a
> gap in the type system. (C99 allows extended integer types, with
> appropriate typedefs in <stdint.h>, but portable code can't yet depend
> on this.)
>
>
> With the understanding that it's undefined behavior regardless
> of the underlying system:
>
> On IA-32: no ouput.
> On IA-64: Segmentation fault.
>
> Here's another program that shows more clearly what's going on:
>
> #ifdef INCLUDE_STDLIB
> #include <stdlib.h>
> #endif
> #include <stdio.h>
> int main()
> {
> char* p;
> p = (char*)malloc(sizeof(char));
> printf("p = %p\n", p);
> fflush(stdout);
> *p = 10;
> return 0;
> }
>
> On IA-32, this produces nearly the same output whether INCLUDE_STDLIB
> is defined or not:
>
> p = 0x8648008
>
> (The specific address changes for some irrelevant reason.)
>
> On IA-64, if INCLUDE_STDLIB is not defined, the output is:
>
> p = 0xc80
> Segmentation fault
>
> If INCLUDE_STDLIB is defined, the output is:
>
> p = 0x6000000000000c80
>
> Of course none if this arises if you just write the code properly in
> the first place: use a "#include <stdlib.h>" directive, and don't cast
> the result of malloc().
Why not cast? Are you saying this in context with the IA-64 thingy or just
as a general thingy? I probably have never understood the need to cast or
not to cast. I seem to consider it to be more of a matter of taste rather
than anything else now. I have seen lot of debate, Bjarne says use cast,
everyone here says no.
--
Imanpreet Singh Arora
If I would have only known, I would have been a locksmith.
-- Albert Einstein
| |
|
| Minti wrote:
> Why not cast? Are you saying this in context with the IA-64
> thingy or just as a general thingy? I probably have never
> understood the need to cast or not to cast. I seem to consider it
> to be more of a matter of taste rather than anything else now. I
> have seen lot of debate, Bjarne says use cast, everyone here says
> no.
You need to tell your friend Bjarne to use a different language.
C++ perhaps?
^_^
| |
| CBFalconer 2004-08-30, 8:55 pm |
| Minti wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message
>
.... snip ...
>
> Why not cast? Are you saying this in context with the IA-64 thingy
> or just as a general thingy? I probably have never understood the
> need to cast or not to cast. I seem to consider it to be more of a
> matter of taste rather than anything else now. I have seen lot of
> debate, Bjarne says use cast, everyone here says no.
He is talking about C++. Here we talk about C. They are not the
same language.
--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
|
|
|
|
|