1 more doubt !

Discussion in 'C Programming' started by maadhuu, Sep 14, 2005.

  1. maadhuu

    maadhuu Guest

    firstly, i am thankful to all those who answered the 1st set of doubts. And
    i am not yet enlightened to that extent , coz ' i keep getting doubts.

    is the following defined in the language ??
    int main()
    {
    int a = 1;
    int *p = &a;
    p++;
    printf("%d",*p);
    return 0;
    }

    thanking you,
    ranjan.
     
    maadhuu, Sep 14, 2005
    #1
    1. Advertising

  2. In article <>,
    maadhuu <> wrote:
    >is the following defined in the language ??


    >int main()


    You should use int main(void) to be consistant with the C standard.

    >{
    > int a = 1;


    Valid.

    > int *p = &a;


    Valid.

    > p++;


    Valid.

    > printf("%d",*p);


    Not valid. It is legal for an object pointer to point one location
    past the end of the object, but it is not legal to dereference the
    pointer so formed.

    > return 0;
    >}

    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
     
    Walter Roberson, Sep 14, 2005
    #2
    1. Advertising

  3. maadhuu wrote:
    > firstly, i am thankful to all those who answered the 1st set of doubts. And
    > i am not yet enlightened to that extent , coz ' i keep getting doubts.
    >
    > is the following defined in the language ??
    > int main()


    this should be "int main (void)"

    > {
    > int a = 1;
    > int *p = &a;


    So far so good.

    > p++;


    What you are doing here is advancing the pointer to point to the space
    right after the location of a. This is well-defined as a special case,
    p+=2 would be undefined behavior.

    > printf("%d",*p);


    You forgot to "#include <stdio.h>".
    Dereferencing p here is undefined behavior.

    > return 0;
    > }


    Robert Gamble
     
    Robert Gamble, Sep 14, 2005
    #3
  4. Robert Gamble wrote:
    > maadhuu wrote:
    > > firstly, i am thankful to all those who answered the 1st set of doubts. And
    > > i am not yet enlightened to that extent , coz ' i keep getting doubts.
    > >
    > > is the following defined in the language ??
    > > int main()

    >
    > this should be "int main (void)"
    >
    > > {
    > > int a = 1;
    > > int *p = &a;

    >
    > So far so good.
    >
    > > p++;

    >
    > What you are doing here is advancing the pointer to point to the space
    > right after the location of a. This is well-defined as a special case,
    > p+=2 would be undefined behavior.


    Why is it well defined?
    Section 6.5.6 of the C99 standard (Additive operators) says

    "Moreover, if the expression P points to the last element of an
    array object, the expression (P)+1 points one past the last
    element of the array object"

    I note that a is not an array object, so p doesn't point to one...
    Am I confused here?

    >
    > > printf("%d",*p);

    >
    > You forgot to "#include <stdio.h>".
    > Dereferencing p here is undefined behavior.
    >


    If it weren't for the deferencing problem, probably wants to be
    printf("%d\n", *p);
    Without the newline, you may not see anything.

    -David
     
    David Resnick, Sep 14, 2005
    #4
  5. In article <>,
    David Resnick <> wrote:
    >Robert Gamble wrote:
    >> > p++;


    >> What you are doing here is advancing the pointer to point to the space
    >> right after the location of a. This is well-defined as a special case,
    >> p+=2 would be undefined behavior.


    >Why is it well defined?
    >Section 6.5.6 of the C99 standard (Additive operators) says


    >"Moreover, if the expression P points to the last element of an
    >array object, the expression (P)+1 points one past the last
    >element of the array object"


    >I note that a is not an array object, so p doesn't point to one...
    >Am I confused here?


    C89 3.3.6

    For the purposes of these operators, a pointer to a nonarray object
    behaves the same as a pointer to the first element of an array of
    length one with a typoe of the object as its element type.
    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
     
    Walter Roberson, Sep 14, 2005
    #5
  6. maadhuu

    maadhuu Guest

    thanx,
    but printing just p, is valid right ???
    and also one more doubt .
    is a ++i ; valid ??? and one more doubt .

    int i = 10;
    int a = ++i + ++i;
    is this also valid ??? because i++ + i++ is invalid ,but there, the side
    effects are present ,and here there shouldn't be any side effects .
     
    maadhuu, Sep 14, 2005
    #6
  7. maadhuu

    maadhuu Guest

    also, i had the same doubt :

    Moreover, if the expression P points to the last element of an
    array object, the expression (P)+1 points one past the last
    element of the array object .

    as was quoted by Mr David from
    Section 6.5.6 of the C99 standard (Additive operators)

    so, does that p++ apply only to arrays or to single objects too ?
    ranjan.
     
    maadhuu, Sep 14, 2005
    #7
  8. "maadhuu" <> wrote:

    Please preserve some context when posting replies.

    >thanx,
    >but printing just p, is valid right ???
    >and also one more doubt .


    Question. You have questions, not doubts.

    >is a ++i ; valid ??? and one more doubt .


    ITYM: a = ++i;

    >int i = 10;
    >int a = ++i + ++i;
    >is this also valid ??? because i++ + i++ is invalid ,but there, the side
    >effects are present ,and here there shouldn't be any side effects .


    ++i has the obvious side effect of incrementing i. Above assignments
    invoke undefined behaviour for the very same reasons as the examples
    you posted in the other thread. And would you, please, read the FAQ,
    as I already suggested?

    Best regards
    --
    Irrwahn Grausewitz ()
    welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
    clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
    clc frequent answers: http://benpfaff.org/writings/clc
     
    Irrwahn Grausewitz, Sep 14, 2005
    #8
  9. Walter Roberson wrote:
    > In article <>,
    > David Resnick <> wrote:
    > >Robert Gamble wrote:
    > >> > p++;

    >
    > >> What you are doing here is advancing the pointer to point to the space
    > >> right after the location of a. This is well-defined as a special case,
    > >> p+=2 would be undefined behavior.

    >
    > >Why is it well defined?
    > >Section 6.5.6 of the C99 standard (Additive operators) says

    >
    > >"Moreover, if the expression P points to the last element of an
    > >array object, the expression (P)+1 points one past the last
    > >element of the array object"

    >
    > >I note that a is not an array object, so p doesn't point to one...
    > >Am I confused here?

    >
    > C89 3.3.6
    >
    > For the purposes of these operators, a pointer to a nonarray object
    > behaves the same as a pointer to the first element of an array of
    > length one with a typoe of the object as its element type.
    > --


    I see now, thanks.

    -David
     
    David Resnick, Sep 14, 2005
    #9
  10. "maadhuu" <> writes:
    > firstly, i am thankful to all those who answered the 1st set of doubts. And
    > i am not yet enlightened to that extent , coz ' i keep getting doubts.
    >
    > is the following defined in the language ??
    > int main()
    > {
    > int a = 1;
    > int *p = &a;
    > p++;
    > printf("%d",*p);
    > return 0;
    > }


    No.

    First, calling printf() without a prototype invokes undefined behavior
    (though it's relatively unlikely to cause any visible problems). Add
    "#include <stdio.h>" to the top of your program.

    The declaration "int main()" is valid, but "int main(void)" is better
    and more explicit.

    It's implementation-defined whether you need a newline at the end of
    your output. Change "%d" to "%d\n".

    Finally (and this is your real problem), after "p++;", p points to a
    nonexistent object just after a. You're allowed to create a pointer
    just past the end of a real object, but any attempt to dereference
    such a pointer invokes undefined behavior.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Sep 14, 2005
    #10
  11. -cnrc.gc.ca (Walter Roberson) writes:
    [...]
    > C89 3.3.6
    >
    > For the purposes of these operators, a pointer to a nonarray object
    > behaves the same as a pointer to the first element of an array of
    > length one with a typoe of the object as its element type.


    Presumably "typoe" was a typoe.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Sep 14, 2005
    #11
  12. maadhuu wrote on 14/09/05 :
    > is the following defined in the language ??
    > int main()
    > {
    > int a = 1;
    > int *p = &a;
    > p++;


    /* OK */

    > printf("%d",*p);


    /* UB */

    > return 0;
    > }


    The syntax is correct, but the behaviour is undefined. You are
    accessing to a memory zone that doesn't belong to you.


    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    ..sig under repair
     
    Emmanuel Delahaye, Sep 14, 2005
    #12
  13. maadhuu

    Novitas Guest

    >firstly, i am thankful to all those who answered the 1st set of doubts. And
    >i am not yet enlightened to that extent , coz ' i keep getting doubts.


    >is the following defined in the language ??
    >int main()
    >{
    > int a = 1;
    > int *p = &a;
    > p++;
    > printf("%d",*p);
    > return 0;
    >
    >}
    >
    >thanking you,
    >ranjan.


    You are clearly in the realm of undefined behavior. And I mean
    undefined in all the senses I alluded to in my earlier replies to your
    earlier query.

    Others have correctly pointed out the issues with your program example
    above.

    Now I have a question (a mildly burning curiousity actually): What
    would you EXPECT such a program to do?

    That is, what do YOU think the program means and what answer are you
    anticipating?

    Or to put it another way, why do you think such a program would be
    valid or produce predictable results?
     
    Novitas, Sep 14, 2005
    #13
  14. Robert Gamble wrote:
    > maadhuu wrote:
    >
    >>firstly, i am thankful to all those who answered the 1st set of doubts. And
    >>i am not yet enlightened to that extent , coz ' i keep getting doubts.
    >>
    >>is the following defined in the language ??
    >>int main()

    >
    >
    > this should be "int main (void)"
    >
    >
    >>{
    >> int a = 1;
    >> int *p = &a;

    >
    >
    > So far so good.
    >
    >
    >> p++;

    >
    >
    > What you are doing here is advancing the pointer to point to the space
    > right after the location of a. This is well-defined as a special case,
    > p+=2 would be undefined behavior.


    How come p += n isn't allowed for n > 1? As long as no dereference takes
    place I can't see any problems with that.


    August
     
    August Karlstrom, Sep 15, 2005
    #14
  15. August Karlstrom wrote:
    > Robert Gamble wrote:
    > > > int a = 1;
    > > > int *p = &a;
    > > > p++;

    > >
    > > What you are doing here is advancing the pointer to point to the space
    > > right after the location of a. This is well-defined as a special case,
    > > p+=2 would be undefined behavior.

    >
    > How come p += n isn't allowed for n > 1? As long as no dereference takes
    > place I can't see any problems with that.


    "Because that's what the standard says." :)

    The reason the standard says this is because it is catering for
    machines
    that can trap purely on the calculation of an invalid address. Also,
    there
    are segmented architectures where p + n - n may not yield the original
    address if n would put the address beyond 'one byte beyond' the
    object's
    memory.

    Conforming implementations on such architectures must still function
    for
    'one byte beyond' situation, but they need not do more than that.

    --
    Peter
     
    Peter Nilsson, Sep 15, 2005
    #15
  16. In article <TX2We.33802$>,
    August Karlstrom <> wrote:
    >Robert Gamble wrote:


    >> What you are doing here is advancing the pointer to point to the space
    >> right after the location of a. This is well-defined as a special case,
    >> p+=2 would be undefined behavior.


    >How come p += n isn't allowed for n > 1? As long as no dereference takes
    >place I can't see any problems with that.


    Segment + offset architectures. Maximum implementation object size
    equals maximum segment offset minus 1; after that, p+n becomes
    officially undefined behaviour and so implementations are allowed to
    wrap the offset (that being as good a choice as any for undefined
    behaviour.)

    To put it another way, pointer -arithmetic- is only guaranteed
    up to one location past the object.

    Keep in mind for this purpose that pointers to different types need not
    be miscible. The int* with arithmetic value 10000 might point to
    a different location than the double* which happens to have
    arithmetic value 10000 . Certain conversions through char*
    and void* are well defined, but those conversions do not
    presume a single linear address space and are defined in such a way
    that it is acceptable to "lose track" of the original value if
    one converts from a pointer with looser alignment requirements
    to a pointer with stricter alignment requirements.
    --
    Any sufficiently advanced bug is indistinguishable from a feature.
    -- Rich Kulawiec
     
    Walter Roberson, Sep 15, 2005
    #16
  17. maadhuu

    Jack Klein Guest

    On Wed, 14 Sep 2005 17:32:36 +0000 (UTC), -cnrc.gc.ca
    (Walter Roberson) wrote in comp.lang.c:

    > In article <>,
    > maadhuu <> wrote:
    > >is the following defined in the language ??

    >
    > >int main()

    >
    > You should use int main(void) to be consistant with the C standard.


    No version of the C standard requires anything inside the parentheses
    in the definition of a function accepting no arguments. This is
    perfectly legal even in C99. Implicit int is gone, so these are not
    legal:

    main()
    main(void)
    main(int agrc, char **argv)

    The only difference between:

    int main()

    ....and:

    int main(void)

    ....is that the latter provides a prototype. And that only provides
    actual added value in the very rare program that happens to call
    main() recursively.

    --
    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, Sep 15, 2005
    #17
  18. maadhuu

    pete Guest

    Jack Klein wrote:
    >
    > On Wed, 14 Sep 2005 17:32:36 +0000 (UTC), -cnrc.gc.ca
    > (Walter Roberson) wrote in comp.lang.c:
    >
    > > In article <>,
    > > maadhuu <> wrote:
    > > >is the following defined in the language ??

    > >
    > > >int main()

    > >
    > > You should use int main(void)
    > > to be consistant with the C standard.

    >
    > No version of the C standard requires anything inside the parentheses
    > in the definition of a function accepting no arguments. This is
    > perfectly legal even in C99. Implicit int is gone, so these are not
    > legal:
    >
    > main()
    > main(void)
    > main(int agrc, char **argv)
    >
    > The only difference between:
    >
    > int main()
    >
    > ...and:
    >
    > int main(void)
    >
    > ...is that the latter provides a prototype. And that only provides
    > actual added value in the very rare program that happens to call
    > main() recursively.


    N869
    6.11.4 Function declarators
    The use of function declarators with empty parentheses
    (not prototype-format parameter type declarators) is an
    obsolescent feature.

    --
    pete
     
    pete, Sep 15, 2005
    #18
  19. In article <>,
    Jack Klein <> wrote:
    >On Wed, 14 Sep 2005 17:32:36 +0000 (UTC), -cnrc.gc.ca
    >(Walter Roberson) wrote in comp.lang.c:


    >> You should use int main(void) to be consistant with the C standard.


    >No version of the C standard requires anything inside the parentheses
    >in the definition of a function accepting no arguments. This is
    >perfectly legal even in C99.


    Not for main it isn't.

    [C89] 2.1.2.2.1 Program Startup

    The function called at program startup is named main. The
    implementation declares no prototype for this function. It can be
    defined with no parameters:

    int main(void) { /*...*/ }

    or with two parameters (referred to here as argc and argv, though
    any names may be used, as they are local to the function in which they
    are declared):

    int main(int argc, char *argv[]) { /*...*/ }


    Notice that C89 did not list the possibility of int main()

    In general, the parameter passing mechanism for a function with
    no arguments may be different than the parameter passing mechanism
    for a function with two arguments, and that passing extra arguments
    to non-vararg functions is UB. Therefor, the implementation may have
    to special-case handling of main() -- and the standard only requires
    that those two particular forms be handled. The declaration of
    main() is special in the standard, and one cannot presume to be true
    any declaration rules that are required for other routines.
    --
    "I want to make sure [a user] can't get through ... an online
    experience without hitting a Microsoft ad"
    -- Steve Ballmer [Microsoft Chief Executive]
     
    Walter Roberson, Sep 15, 2005
    #19
  20. Jack Klein <> wrote:
    >On Wed, 14 Sep 2005 17:32:36 +0000 (UTC), -cnrc.gc.ca
    >(Walter Roberson) wrote in comp.lang.c:
    >
    >> In article <>,
    >> maadhuu <> wrote:
    >> >is the following defined in the language ??

    >>
    >> >int main()

    >>
    >> You should use int main(void) to be consistant with the C standard.

    >
    >No version of the C standard requires anything inside the parentheses
    >in the definition of a function accepting no arguments. This is
    >perfectly legal even in C99. Implicit int is gone, so these are not
    >legal:
    >
    > main()
    > main(void)
    > main(int agrc, char **argv)
    >
    >The only difference between:
    >
    > int main()
    >
    >...and:
    >
    > int main(void)
    >
    >...is that the latter provides a prototype. And that only provides
    >actual added value in the very rare program that happens to call
    >main() recursively.


    According to the standard (C99 5.1.2.2.1p1), only the following
    two definitions of main are guaranteed to be valid:

    int main(void) { /* ... */ }
    int main(int argc, char *argv[]) { /* ... */ }

    Of course, other definitions may be allowed by a particular
    implementation, but that's not the point.

    Best regards
    --
    Irrwahn Grausewitz ()
    welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
    clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
    clc frequent answers: http://benpfaff.org/writings/clc
     
    Irrwahn Grausewitz, Sep 16, 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. Michael
    Replies:
    4
    Views:
    466
    Matt Hammond
    Jun 26, 2006
  2. Bob Nelson

    doubt about doubt

    Bob Nelson, Jul 28, 2006, in forum: C Programming
    Replies:
    11
    Views:
    659
  3. Replies:
    0
    Views:
    592
  4. Peter Otten
    Replies:
    2
    Views:
    138
    Cousin Stanley
    Aug 10, 2013
  5. Terry Reedy
    Replies:
    0
    Views:
    135
    Terry Reedy
    Aug 10, 2013
Loading...

Share This Page