help me understanding this

karri's Avatar, Join Date: Jun 2007
Light Poster
Code:
main()
{
  char *p;
  char buf[10] ={ 1,2,3,4,5,6,9,8};
  p = (buf+1)[5];
  printf("%d" , p);
}
In this though an integer is assigned to a pointer it is not showing any error and in the printf statement it is printing the value inspite of the address.

Last edited by shabbir; 6Jun2007 at 08:41.. Reason: Code block - http://www.go4expert.com/forums/misc.php?do=bbcode#code
0
DaWei's Avatar, Join Date: Dec 2006
Team Leader
You are not assigning an integer. You are assigning a pointer value determined by pointer arithmetic. In your statement, buf is behaving as a pointer (as dictated by the standard); you are adding 1 to it, then adding 5 to it.

Be a big boy; learn to use code tags.
0
karri's Avatar, Join Date: Jun 2007
Light Poster
sry for not using code tags....

say for instance to assign an array element to a character i would do
c = array[n];
here i is an integer
In the above problem by (array+1)[5] doesn't it mean array + 1 is a pointer to next element pointed by pointer array let it be arraynext
so arraynext[5] would mean *(arraynext + 5) which is a character and how is it assigned to a pointer.

As u said if it is a pointer why is it printing 9 instead of the address of the corresponding element
0
kaustubh's Avatar, Join Date: Aug 2007
Go4Expert Member
hi karri,
I am not sure , but i think buf refers to first element , (buf + 1) refers to second element and [5] means shift to 5 elements ahead. Then it will go to 7th element.
If you have gcc or cl you can create assembly code and see how its working.
For creating assembly code type gcc -S filename.c or for cl type cl /Fa filename.c

kaustubh.
0
kaustubh's Avatar, Join Date: Aug 2007
Go4Expert Member
hi karri,

look here the assembly code

Code:
; Line 6
	mov	BYTE PTR _buf$[ebp], 1
	mov	BYTE PTR _buf$[ebp+1], 2
	mov	BYTE PTR _buf$[ebp+2], 3
	mov	BYTE PTR _buf$[ebp+3], 4     ;  the array char buf[10] ={ 1,2,3,4,5,6,9,8};
	mov	BYTE PTR _buf$[ebp+4], 5
	mov	BYTE PTR _buf$[ebp+5], 6
	mov	BYTE PTR _buf$[ebp+6], 9
	mov	BYTE PTR _buf$[ebp+7], 8
	xor	eax, eax
	mov	WORD PTR _buf$[ebp+8], ax
; Line 7
	movsx	ecx, BYTE PTR _buf$[ebp+6] ; p = (buf+1)[5];
	mov	DWORD PTR _p$[ebp], ecx;
now you can see here p refers to buf[6] element .
so if arraynext[5] mean *(arraynext + 5)
then (buf + 1)[5] means *(buf + 1 + 5)
means *(buf + 6)
0
kaustubh's Avatar, Join Date: Aug 2007
Go4Expert Member
hi karri,
try this
Code:
# include<stdio.h>

main()
{
char *p;
  char buf[10] ={ 1,2,3,4,5,6,9,8};
   p = (buf)[5];
  printf("%d",p);

}
here we can say buf means first element and p = (buf)[5] means *(first element + 5)
Another thing i forgot to mention you is that array starts from 0 .
buf[0] = 1
buf[1] = 2
buf[2] = 3
buf[3] = 4
buf[4] = 5
buf[5] = 6
buf[6] =9
buf[7] = 8
0
DaWei's Avatar, Join Date: Dec 2006
Team Leader
That's a lot of nonsense for nothing. buf+1 [5] results in pointer arithmetic being performed, therefore it means buf [6]. buf [6] is a character. p is a pointer. Assigning buf [6] to p should result in an error. If your compiler does not give you an error, either turn on all errors and warnings or, if they are on, get a decent compiler.

Also, main is defined as returning an int.
Code:
int main ()
{
    ....
    return 0; /* for success, non zero for failure */
}
0
kaustubh's Avatar, Join Date: Aug 2007
Go4Expert Member
It does work in c with 100% success, but it will not work in c++. I have tried it.
0
DaWei's Avatar, Join Date: Dec 2006
Team Leader
You are falling into a deadly trap. Even in C, which is less strongly typed than C++, your compiler should issue a warning.

The MS compiler issues two:
warning C4047: '=' : 'char *' differs in levels of indirection from 'char'
warning C4313: 'printf' : '%d' in format string conflicts with argument 1 of type 'char *'

The GCC compiler issues one:
warning: assignment makes pointer from integer without a cast

Warnings are almost always errors. The difference is that the compiler will be allowed to produce some code that does something. It MIGHT actually even do something precisely as you expect.

In those areas that the standard defines as "undefined behavior" or "implementation defined behavior" the compiler writer is not constrained. He may produce an ouput that performs exactly as you would like. On the next version he may produce output that burns your house down. Either is acceptable.

Correctness is not defined by the conformance of a compiler to your expectations. Correctness is defined by the standard and the compliance of a compiler is judged by that standard.

A judgement of 100% success, even if true today, is flawed if the behavior is undefined or implementation defined.

What am I saying? I am saying turn on all warnings and errors and heed them. I am saying write code correctly. Do not accept incorrect code, even if it "works" for you. It will return and bite you squarely in the *** one day.