strange program- shows not output

Hi,

the following code compiles well but its nt showing output. Please specify what may be the error..

Code:

#include<stdio.h>

  #define TOTAL_ELEMENTS (sizeof(array) / sizeof(array[0]))
  int array[] = {23,34,12,17,204,99,16};

  int main()
  {
      int d;

      for(d=-1;d <= (TOTAL_ELEMENTS-2);d++)
          printf("%d\n",array[d+1]);

      return 0;
  }

Thanks

 

In the for loop, value of D must be initialized to 0 instead of -1.
for(d=0;........)
:happy:

 

thats fine.. but what is going wrong when d=-1 ?

Thanks

 

try this

Code:

#include<stdio.h>

  #define TOTAL_ELEMENTS (sizeof(array) / sizeof(array[0]))
  int array[] = {23,34,12,17,204,99,16};

  int main()
  {
      int d;
      int t=(TOTAL_ELEMENTS-2);
      printf("\ntotal elements=%d\n",t);
      for(d=-1;d <= t;d++)
          printf("%d\n",array[d+1]);
      return 0;
  }

 

It goes wrong because TOTAL_ELEMENTS evaluates to an unsigned int. This also displays no output:

Code:

	int d;

	unsigned int t=TOTAL_ELEMENTS-2;
	for(d=-1;d <= t;d++)
		printf("%d\n",array[d+1]);

You compiler should give you a warning. I got (in Visual Studio 2008):
warning C4018: '<=' : signed/unsigned mismatch

The problem with comparing signed with unsigned is that the signed number is treated as unsigned. -1 is 0xFFFFFFFF, which as an unsigned int has the value over 4 billion, which is not less than or equal to TOTAL_ELEMENTS (7), so you get no output.

No, this is absolutely false. It makes no difference what the start and stop values of d are, as long as a suitable offset is added when d is used as the index of an array, IF the pointer used is at the start of the array. This works perfectly:

Code:

	int d, *arr=&array[3];
	
	for (d=-3; d<4; d++)
		printf("%d ",arr[d]);
	printf("\n");
	for (d=-3; d<4; d++)
		printf("%d ",array[d+3]);

Both loops are from -3 to +3 (7 elements). The first loop displays arr[-3] to arr[3], which corresponds to array[0] to array[6] because arr points at array[3]. The second loop displays array[-3+3] to array[3+3], i.e. array[0] to array[6].

 

Thanks a ton xpi0t0s!! Its was a great info!!:happy:

 

Code:

 int main()
  {
      int* p;
      p = (int*)malloc(sizeof(int));
      *p = 10;
      return 0;
  }

Though this works fine on IA-32, but does not work on IA-64. I am not able to find the answer,why it is so.

Please tell me.

Thanks

 

How exactly doesn't it work? There is no output. What are you expecting, and what did you observe that didn't match your expectations? What OS are you using - IA32/IA6 is a processor architecture, and runs several different OS's.

 

Could it be that sizeof(int) != sizeof(int *) in 64 bit?

 

Why would that make any difference? p is a pointer to int. malloc allocates space for an int and returns the pointer, cast to an int* to avoid compiler warnings, into p. The next line then dereferences p and plonks 10 into it. Should work fine, i.e. set *p, which is an int, to 10.

In fact the code should be identical to

Code:

int p;
p=10;
malloc(sizeof(int)); // to duplicate the memory leak in the original code

 

it was asked by someone to me. I have only IA32.

The int* is unsigned integer (as pointing to an address) and int both have same size of 64bits on IA-64. So at least i do not see any problem with the code.

 

Perhaps that's the problem. An int* is NOT an unsigned integer; it is a pointer to a signed integer. These are not the same thing. So maybe the problem is with the interpretation of code (int*=unsigned int) rather than the code itself.

On a 64-bit platform pointers may be 64-bit. int may still only be 32-bit - it depends on how the compiler author implements the 32 to 64-bit upgrade. Upgrading ints to 64-bit might (a) be unnecessary and (b) break too much existing code, so for example Microsoft have chosen to leave int as 32-bit and you need a different type if you actually want a 64-bit integer.