/*
* Please try to answer this question. There is no time bound.
* The following C program segfaults of IA-64,
* but works fine on IA-32.
*/
int main()
{
int* p;
p = (int*)malloc(sizeof(int));
*p = 10;
return 0;
}
>/* Why does it happen so? */
/* Can any body explain to me this? I got this prob. from one of my friends. */
Did you recompile it for your 64 bit architecture?
If not maybe the compiler optimised away the sizeof(int) causing malloc to allocate space for a 32 bit int.
Then when you run on a 64 bit system where the assignment would try to write a 64 bit number, boom.
Just speculation but could be worth looking into...
#include <stdlib.h>I'd kinda assumed it was a snippet rather than a complete source ;)
I don't know what IA-64 and IA-32 refer to. Is that a particular hardware standard?
Typically segfaults of this type are because your CPU demands that shorts be aligned on short boundaries, longs on long boundaries and so on. So if 'int' is 64 bits on some machine, it may need to be on a 64 bit boundary. This isn't true for all hardware, of course.
Compare Intel x86 to ARM; on x86 a long can be aligned on anything, but on ARM it must be aligned on a 4-byte boundary.
So, for the sample code provided, it isn't clear to me what is wrong unless the malloc does not return aligned data. Malloc implementations I've seen on systems that care (and most that don't) return data aligned on some large (8 or 16) byte boundary to avoid this problem.
IA-64 if I'm not mistaken is a 64 bit AMD CPU, that would make IA-32 it's 32 bit equivalent.
64 bits is 8 bytes, so if malloc returns data alligned on 4 bytes he's in trouble unless he recompiles.
Many compilers I think have compiler flags to set byte allignment.
Yes jwenting,
I recompile it for my 64-bit architecture but it gives the same error.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.