Initializing Pointer to an array

Discussion in 'C Programming' started by rupesh_533@rediffmail.com, Oct 20, 2005.

  1. Guest

    I am assuming the following things.
    1.Pointer to an integer means it points to an integer,On incrementing
    the pointer,it points to the next integer in memory.
    2.Pointer to an array of some size means it points to an array,On
    incrementing the pointer,it should point to next array of that size.

    Correct me if i am wrong.
    We declare a pointer to an integer array of Size N as
    int (*a)[N];

    Now My Problem is
    I have an array of 100 Integers,Pointer to an array of 10 integers
    int (*a)[10];
    int b[100];
    How can i initialize the pointer a to point to the array b base
    address.
     
    , Oct 20, 2005
    #1
    1. Advertising

  2. Guest

    I am able to initialize the pointer to the array as
    int (*a)[10];
    int b[100];

    a = &b[0];
    But i am getting the warning
    warning: assignment from incompatible pointer type

    My Code is
    int main()
    {
    int (*a)[10];
    int b[100];
    int i;

    for(i=0;i<100;i++)
    b=i;

    a = &b[0];

    printf(" %u %u %d %d\n",a ,&b[0],**a,b[0]);
    a++;
    printf(" %u %u %d %d\n",a ,&b[10],**a,b[10]);
    a++;
    printf(" %u %u %d %d\n",a , &b[20],**a,b[20]);
    a++;
    printf(" %u %u %d %d\n",a , &b[30],**a,b[30]);
    }

    I am getting correct results as
    3221219184 3221219184 0 0
    3221219224 3221219224 10 10
    3221219264 3221219264 20 20
    3221219304 3221219304 30 30
     
    , Oct 20, 2005
    #2
    1. Advertising

  3. wrote:

    > I am able to initialize the pointer to the array as
    > int (*a)[10];
    > int b[100];


    > a = &b[0];
    > But i am getting the warning
    > warning: assignment from incompatible pointer type


    Of course you are. a is a pointer to an array of 10 ints (which
    you probably do not need), while &b[0] is a pointer to an int. Your
    compiler is doing you a favor.

    > My Code is
    > int main()


    int main( void ) /* better */

    > {
    > int (*a)[10];
    > int b[100];
    > int i;


    > for(i=0;i<100;i++)


    for( i=0; i < sizeof b; i++) /* better */

    > b=i;


    > a = &b[0];


    Wrong, as I said.

    > printf(" %u %u %d %d\n",a ,&b[0],**a,b[0]);


    Wrong in multiple ways:

    1) You did not include <stdio.h>.
    2) %u is not the conversion specifier you want for pointers.

    printf( " %p %p %d %d\n", (void*)a, (void*)&b[0], **a, b[0] );

    Note the casts; they are required.

    > a++;
    > printf(" %u %u %d %d\n",a ,&b[10],**a,b[10]);
    > a++;
    > printf(" %u %u %d %d\n",a , &b[20],**a,b[20]);
    > a++;
    > printf(" %u %u %d %d\n",a , &b[30],**a,b[30]);


    Unless you are using a C99 compiler, you must return a value from
    main(). Your compiler should have warned you about this unfortunate
    omission.

    > }


    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 20, 2005
    #3
  4. Christopher Benson-Manica wrote:

    <snipped rest of code>

    > wrote:
    > > int main()

    >
    > int main( void ) /* better */
    >
    > > {
    > > int (*a)[10];
    > > int b[100];
    > > int i;

    >
    > > for(i=0;i<100;i++)

    >
    > for( i=0; i < sizeof b; i++) /* better */
    >


    Shouldn't that be:
    for (i = 0; i < ((sizeof b) / (sizeof int)); i++)
    ??
     
    Antonio Contreras, Oct 20, 2005
    #4
  5. Antonio Contreras <> wrote:

    > for (i = 0; i < ((sizeof b) / (sizeof int)); i++)


    Yes. Ouch. (And thank you.)

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 20, 2005
    #5
  6. Flash Gordon Guest

    Christopher Benson-Manica wrote:
    > Antonio Contreras <> wrote:
    >
    >>for (i = 0; i < ((sizeof b) / (sizeof int)); i++)

    >
    > Yes. Ouch. (And thank you.)


    Or better yet:
    for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)

    Then it will compile (apart from being incomplete and the certainty of
    me introducing an error in my correction) and be independant of the type
    of array b.

    :)
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
     
    Flash Gordon, Oct 20, 2005
    #6
  7. Flash Gordon wrote:
    > Christopher Benson-Manica wrote:
    > > Antonio Contreras <> wrote:
    > >
    > >>for (i = 0; i < ((sizeof b) / (sizeof int)); i++)

    > >
    > > Yes. Ouch. (And thank you.)

    >
    > Or better yet:
    > for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)
    >
    > Then it will compile (apart from being incomplete and the certainty of
    > me introducing an error in my correction) and be independant of the type
    > of array b.
    >
    > :)


    Well, for purely aesthetic reasons I would prefer the totally
    equivalent:

    for (i = 0; i < ((sizeof b) / (sizeof b[0])); i++)

    Call me paranoid, but the equivalence between arrays and pointers is
    confusing enough [1] without dereferencing pointers that have been
    created by the decay of an array name.

    [1] Actually I've gotten used to it and it's not confusing anymore, but
    it was really confusing two years ago.
     
    Antonio Contreras, Oct 20, 2005
    #7
  8. In article <>, "Antonio Contreras" <> writes:
    > Christopher Benson-Manica wrote:
    > > wrote:
    > > > int (*a)[10];
    > > > int b[100];
    > > > int i;

    > >
    > > > for(i=0;i<100;i++)

    > >
    > > for( i=0; i < sizeof b; i++) /* better */

    >
    > Shouldn't that be:
    > for (i = 0; i < ((sizeof b) / (sizeof int)); i++)


    When the sizeof operator is applied to a type, the name of the type
    must be parenthesized. You're missing parentheses around "int"
    (which is ironic, considering all the unnecessary sets of parentheses
    you have there).

    What would be better is

    for (i = 0; i < sizeof b / sizeof *b; i++)

    which works for a "b" of any (complete) array type.

    --
    Michael Wojcik

    Global warming is just a theory. This is Intelligent Defrosting. -- "Gregg"
     
    Michael Wojcik, Oct 20, 2005
    #8
  9. Christopher Benson-Manica wrote:
    >
    > Unless you are using a C99 compiler, you must return a value from
    > main().


    It's not mandatory un C90, just desirable.

    > Your compiler should have warned you about this unfortunate
    > omission.


    Perhaps, but unlike C++, both C90 and C99 allow non-void functions to
    fail
    to return a value. So long as the calling function doesn't attempt to
    use
    the value, all is fine.

    As this is a <cough> feature of the language, many old compilers won't
    issue a warning for this.

    --
    Peter
     
    Peter Nilsson, Oct 21, 2005
    #9
  10. Jack Klein Guest

    On 20 Oct 2005 15:36:14 -0700, "Antonio Contreras" <>
    wrote in comp.lang.c:

    > Flash Gordon wrote:
    > > Christopher Benson-Manica wrote:
    > > > Antonio Contreras <> wrote:
    > > >
    > > >>for (i = 0; i < ((sizeof b) / (sizeof int)); i++)
    > > >
    > > > Yes. Ouch. (And thank you.)

    > >
    > > Or better yet:
    > > for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)
    > >
    > > Then it will compile (apart from being incomplete and the certainty of
    > > me introducing an error in my correction) and be independant of the type
    > > of array b.
    > >
    > > :)

    >
    > Well, for purely aesthetic reasons I would prefer the totally
    > equivalent:
    >
    > for (i = 0; i < ((sizeof b) / (sizeof b[0])); i++)
    >
    > Call me paranoid, but the equivalence between arrays and pointers is
    > confusing enough [1] without dereferencing pointers that have been
    > created by the decay of an array name.


    The sizeof operator never evaluates the value of its operand in C
    prior to C99, and only to determine the size of a variable length
    array in C99. Under no circumstances does sizeof dereference a
    pointer given to it as an argument.

    Plus the C language absolutely requires that the expression b[0] be
    evaluated as if written *b, so the Christopher's code and your
    alternative are exactly equivalent in C.

    > [1] Actually I've gotten used to it and it's not confusing anymore, but
    > it was really confusing two years ago.


    In either case, there is no evaluation of the value of b[0] or *b, and
    no dereference.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Oct 21, 2005
    #10
  11. Peter Nilsson <> wrote:

    > It's not mandatory un C90, just desirable.


    I suppose that's strictly correct, but it's probably safe to assume
    that a reasonable host environment will attempt to use the termination
    status of main. I would think that the chances of UB on a hosted
    implentation would be rather high.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 21, 2005
    #11
  12. Zara Guest

    On Fri, 21 Oct 2005 14:34:06 +0000 (UTC), Christopher Benson-Manica
    <> wrote:

    >Peter Nilsson <> wrote:
    >
    >> It's not mandatory un C90, just desirable.

    >
    >I suppose that's strictly correct, but it's probably safe to assume
    >that a reasonable host environment will attempt to use the termination
    >status of main. I would think that the chances of UB on a hosted
    >implentation would be rather high.


    C *and* C++ specify that reaching the the terminating } of main() will
    return 0; so this function *always* return a valid value.
     
    Zara, Oct 21, 2005
    #12
  13. Zara <> wrote:

    > C *and* C++ specify that reaching the the terminating } of main() will
    > return 0; so this function *always* return a valid value.


    C89 does not.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 21, 2005
    #13
  14. Flash Gordon Guest

    Christopher Benson-Manica wrote:
    > Zara <> wrote:
    >
    >>C *and* C++ specify that reaching the the terminating } of main() will
    >>return 0; so this function *always* return a valid value.

    >
    > C89 does not.


    And, just to emphasise the point, there are far more people using
    implementations that can support C89 correctly (modulo bugs) than there
    are people using conforming C99 implementations. For a start, neither
    gcc nor MS VC++ fully support C99 but both fully support C89 (modulo bugs).
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
     
    Flash Gordon, Oct 21, 2005
    #14
  15. Tim Rentsch Guest

    Jack Klein <> writes:

    > Plus the C language absolutely requires that the expression b[0] be
    > evaluated as if written *b,


    Usually but not always.

    void
    foo(){
    int a[10];
    int (*b)[] = &a;
    int *c;

    c = b[0]; /* this doesn't work */
    c = *b; /* this works */
    }

    Personally, I'd be in favor of adding a rule that makes the two
    forms equivalent in the case of a 0-valued constant expression.
    But that's another story.
     
    Tim Rentsch, Oct 21, 2005
    #15
  16. Jack Klein wrote:
    > On 20 Oct 2005 15:36:14 -0700, "Antonio Contreras" <>
    > wrote in comp.lang.c:
    >
    > > Flash Gordon wrote:
    > > > Christopher Benson-Manica wrote:
    > > > > Antonio Contreras <> wrote:
    > > > >
    > > > >>for (i = 0; i < ((sizeof b) / (sizeof int)); i++)
    > > > >
    > > > > Yes. Ouch. (And thank you.)
    > > >
    > > > Or better yet:
    > > > for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)
    > > >
    > > > Then it will compile (apart from being incomplete and the certainty of
    > > > me introducing an error in my correction) and be independant of the type
    > > > of array b.
    > > >
    > > > :)

    > >
    > > Well, for purely aesthetic reasons I would prefer the totally
    > > equivalent:
    > >
    > > for (i = 0; i < ((sizeof b) / (sizeof b[0])); i++)
    > >
    > > Call me paranoid, but the equivalence between arrays and pointers is
    > > confusing enough [1] without dereferencing pointers that have been
    > > created by the decay of an array name.

    >
    > The sizeof operator never evaluates the value of its operand in C
    > prior to C99, and only to determine the size of a variable length
    > array in C99. Under no circumstances does sizeof dereference a
    > pointer given to it as an argument.


    I didn't imply that. What I tried to say is that it "looks" like it,
    and that it is confusing when you're learning C. IMHO, given that b is
    an array, b[0] is less confusing than *b.

    > Plus the C language absolutely requires that the expression b[0] be
    > evaluated as if written *b, so the Christopher's code and your
    > alternative are exactly equivalent in C.


    I acknowledge that much. I literally said "I prefer the _totally
    equivalent_..."

    > > [1] Actually I've gotten used to it and it's not confusing anymore, but
    > > it was really confusing two years ago.

    >
    > In either case, there is no evaluation of the value of b[0] or *b, and
    > no dereference.


    Again, I didn't try to imply that. I guess it was a really bad wording
    from my side.
     
    Antonio Contreras, Oct 21, 2005
    #16
  17. On 21 Oct 2005 12:22:00 -0700, Tim Rentsch <>
    wrote:

    >Jack Klein <> writes:
    >
    >> Plus the C language absolutely requires that the expression b[0] be
    >> evaluated as if written *b,

    >
    >Usually but not always.
    >
    > void
    > foo(){
    > int a[10];
    > int (*b)[] = &a;
    > int *c;
    >
    > c = b[0]; /* this doesn't work */
    > c = *b; /* this works */


    Are you sure? n1124 states in 6.5.2.1(2) that

    A postfix expression followed by an expression in square brackets []
    is a subscripted designation of an element of an array object. The
    definition of the subscript operator [] is that E1[E2] is identical to
    (*((E1)+(E2))). Because of the conversion rules that apply to the
    binary + operator, if E1 is an array object (equivalently, a pointer
    to the initial element of an array object) and E2 is an integer,
    E1[E2] designates the E2-th element of E1 (counting from zero).

    So b[0] is the same as *(b+0) which is the same as *b. Both
    expressions should evaluate to the address of a with type array of 10
    int which, since it is not one of the exceptions, will then be
    converted to the address of a[0] with type pointer to int.

    > }
    >
    >Personally, I'd be in favor of adding a rule that makes the two
    >forms equivalent in the case of a 0-valued constant expression.
    >But that's another story.



    <<Remove the del for email>>
     
    Barry Schwarz, Oct 22, 2005
    #17
  18. S.Tobias Guest

    Barry Schwarz <> wrote:
    > On 21 Oct 2005 12:22:00 -0700, Tim Rentsch <>
    > wrote:
    >>Jack Klein <> writes:
    >>
    >>> Plus the C language absolutely requires that the expression b[0] be
    >>> evaluated as if written *b,

    >>
    >>Usually but not always.
    >>
    >> void
    >> foo(){
    >> int a[10];
    >> int (*b)[] = &a;
    >> int *c;
    >>
    >> c = b[0]; /* this doesn't work */
    >> c = *b; /* this works */

    >
    > Are you sure? n1124 states in 6.5.2.1(2) that
    >
    > A postfix expression followed by an expression in square brackets []
    > is a subscripted designation of an element of an array object. The
    > definition of the subscript operator [] is that E1[E2] is identical to
    > (*((E1)+(E2))). Because of the conversion rules that apply to the
    > binary + operator, if E1 is an array object (equivalently, a pointer
    > to the initial element of an array object) and E2 is an integer,
    > E1[E2] designates the E2-th element of E1 (counting from zero).
    >
    > So b[0] is the same as *(b+0) which is the same as *b.


    They are not the same. `b+0' has an additional constraint:
    6.5.6#2
    # [#2] For addition, either both operands shall have
    # arithmetic type, or one operand shall be a pointer to an
    # object type and the other shall have integer type.

    ("Object type" is a complete type.)

    >Both
    > expressions should evaluate to the address of a with type array of 10
    > int which,


    `*b' is an incomplete (array) type lvalue.

    >since it is not one of the exceptions, will then be
    > converted to the address of a[0] with type pointer to int.


    Yes.

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Oct 22, 2005
    #18
  19. Flash Gordon Guest

    S.Tobias wrote:
    > Barry Schwarz <> wrote:
    >
    >>On 21 Oct 2005 12:22:00 -0700, Tim Rentsch <>
    >>wrote:
    >>
    >>>Jack Klein <> writes:
    >>>
    >>>
    >>>>Plus the C language absolutely requires that the expression b[0] be
    >>>>evaluated as if written *b,
    >>>
    >>>Usually but not always.
    >>>
    >>> void
    >>> foo(){
    >>> int a[10];
    >>> int (*b)[] = &a;
    >>> int *c;
    >>>
    >>> c = b[0]; /* this doesn't work */
    >>> c = *b; /* this works */

    >>
    >>Are you sure? n1124 states in 6.5.2.1(2) that
    >>
    >>A postfix expression followed by an expression in square brackets []
    >>is a subscripted designation of an element of an array object. The
    >>definition of the subscript operator [] is that E1[E2] is identical to
    >>(*((E1)+(E2))). Because of the conversion rules that apply to the
    >>binary + operator, if E1 is an array object (equivalently, a pointer
    >>to the initial element of an array object) and E2 is an integer,
    >>E1[E2] designates the E2-th element of E1 (counting from zero).
    >>
    >>So b[0] is the same as *(b+0) which is the same as *b.

    >
    >
    > They are not the same. `b+0' has an additional constraint:
    > 6.5.6#2
    > # [#2] For addition, either both operands shall have
    > # arithmetic type, or one operand shall be a pointer to an
    > # object type and the other shall have integer type.
    >
    > ("Object type" is a complete type.)


    Yes.

    >>Both
    >>expressions should evaluate to the address of a with type array of 10
    >>int which,

    >
    > `*b' is an incomplete (array) type lvalue.


    *b being an incomplete type is irrelevant since it is *(b+0) NOT *b +0
    so 0 is added to b not to *b.

    >>since it is not one of the exceptions, will then be
    >>converted to the address of a[0] with type pointer to int.

    >
    > Yes.

    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
     
    Flash Gordon, Oct 22, 2005
    #19
  20. S.Tobias Guest

    Flash Gordon <> wrote:
    > S.Tobias wrote:
    >> Barry Schwarz <> wrote:
    >>>On 21 Oct 2005 12:22:00 -0700, Tim Rentsch <>
    >>>wrote:


    >>>> void
    >>>> foo(){
    >>>> int a[10];
    >>>> int (*b)[] = &a;
    >>>> int *c;
    >>>>
    >>>> c = b[0]; /* this doesn't work */
    >>>> c = *b; /* this works */


    [snip]
    >>>So b[0] is the same as *(b+0) which is the same as *b.

    ....
    >>>Both
    >>>expressions should evaluate to the address of a with type array of 10
    >>>int which,

    >>
    >> `*b' is an incomplete (array) type lvalue.

    >
    > *b being an incomplete type is irrelevant since it is *(b+0) NOT *b +0
    > so 0 is added to b not to *b.
    >

    Right. I did mean `*b', but I misunderstood what Barry had said, so my
    answer was irrelevant, too.

    One more try: `*b' evaluates to an incomplete array type lvalue
    for the array `a', which is immediately converted to the pointer to
    the first element of `a' (not: "to the address of `a'"; unless "address"
    is understood as "location").

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Oct 24, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sangeetha

    Array of pointer Vs Pointer to Array

    sangeetha, Oct 8, 2004, in forum: C Programming
    Replies:
    9
    Views:
    355
    Tim Rentsch
    Oct 9, 2004
  2. arun

    initializing array using pointer

    arun, Dec 13, 2005, in forum: C Programming
    Replies:
    31
    Views:
    1,143
    Richard Bos
    Dec 15, 2005
  3. erfan

    Array of pointer and pointer of array

    erfan, Jan 28, 2008, in forum: C Programming
    Replies:
    6
    Views:
    682
    Martin Ambuhl
    Jan 28, 2008
  4. RSL
    Replies:
    14
    Views:
    3,319
  5. , India

    pointer to an array vs pointer to pointer

    , India, Sep 20, 2011, in forum: C Programming
    Replies:
    5
    Views:
    467
    James Kuyper
    Sep 23, 2011
Loading...

Share This Page