Go4Expert (http://www.go4expert.com/)
-   C (http://www.go4expert.com/forums/c/)
-   -   help me understanding this (http://www.go4expert.com/forums/help-understanding-t4570/)

karri 6Jun2007 00:55

help me understanding this

  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.

DaWei 6Jun2007 05:21

Re: help me understanding this
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.

karri 6Jun2007 14:17

Re: help me understanding this
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

kaustubh 13Aug2007 14:42

Re: help me understanding this
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 13Aug2007 15:19

Re: help me understanding this
hi karri,

look here the assembly 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)

kaustubh 13Aug2007 15:38

Re: help me understanding this
hi karri,
try this

# include<stdio.h>

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


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

DaWei 13Aug2007 16:27

Re: help me understanding this
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.

int main ()
    return 0; /* for success, non zero for failure */

kaustubh 13Aug2007 17:26

Re: help me understanding this
It does work in c with 100% success, but it will not work in c++. I have tried it.

DaWei 13Aug2007 19:58

Re: help me understanding this
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.

All times are GMT +5.5. The time now is 19:30.