Implementation-defined behaviour

Discussion in 'C Programming' started by Ioannis Vranos, Mar 28, 2008.

  1. AFAIK the following is implementation-defined behaviour, am I right?:


    #include <stdio.h>


    int main(void)
    {
    int n= 0;

    printf("%d\n", n++);


    return 0;
    }
     
    Ioannis Vranos, Mar 28, 2008
    #1
    1. Advertising

  2. Ioannis Vranos

    santosh Guest

    Ioannis Vranos wrote:

    > AFAIK the following is implementation-defined behaviour, am I right?:
    >
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > int n= 0;
    > printf("%d\n", n++);
    > return 0;
    > }


    I don't think so.
     
    santosh, Mar 28, 2008
    #2
    1. Advertising

  3. Ioannis Vranos

    Eric Sosman Guest

    Ioannis Vranos wrote:
    > AFAIK the following is implementation-defined behaviour, am I right?:
    >
    >
    > #include <stdio.h>
    >
    >
    > int main(void)
    > {
    > int n= 0;
    >
    > printf("%d\n", n++);
    >
    >
    > return 0;
    > }


    Only by quibbles: the form of "successful termination"
    returned to the host environment is implementation-defined,
    the actual new-line representation written to stdout in
    response to the '\n' is implementation-defined, and things
    of that sort.

    What aspect do you believe is not Standard-defined?

    --
    Eric Sosman
    lid
     
    Eric Sosman, Mar 28, 2008
    #3
  4. santosh wrote:
    > Ioannis Vranos wrote:
    >
    >> AFAIK the following is implementation-defined behaviour, am I right?:
    >>
    >> #include <stdio.h>
    >>
    >> int main(void)
    >> {
    >> int n= 0;
    >> printf("%d\n", n++);
    >> return 0;
    >> }

    >
    > I don't think so.


    There are similar examples at 2.12 of K&R2.


    Two quotes from there:

    "printf("%d %d\n", ++n, power(2, n)); /* WRONG */"


    "One unhappy situation is typified by the statement

    a= i++;"
     
    Ioannis Vranos, Mar 28, 2008
    #4
  5. Eric Sosman wrote:
    > Ioannis Vranos wrote:
    >> AFAIK the following is implementation-defined behaviour, am I right?:
    >>
    >>
    >> #include <stdio.h>
    >>
    >>
    >> int main(void)
    >> {
    >> int n= 0;
    >>
    >> printf("%d\n", n++);
    >>
    >>
    >> return 0;
    >> }

    >
    > Only by quibbles: the form of "successful termination"
    > returned to the host environment is implementation-defined,
    > the actual new-line representation written to stdout in
    > response to the '\n' is implementation-defined, and things
    > of that sort.
    >
    > What aspect do you believe is not Standard-defined?



    I am talking about the implementation-defined behaviour of the printf()
    call described at 2.12 of K&R2.
     
    Ioannis Vranos, Mar 28, 2008
    #5
  6. Ioannis Vranos

    santosh Guest

    Ioannis Vranos wrote:

    > santosh wrote:
    >> Ioannis Vranos wrote:
    >>
    >>> AFAIK the following is implementation-defined behaviour, am I
    >>> right?:
    >>>
    >>> #include <stdio.h>
    >>>
    >>> int main(void)
    >>> {
    >>> int n= 0;
    >>> printf("%d\n", n++);
    >>> return 0;
    >>> }

    >>
    >> I don't think so.

    >
    > There are similar examples at 2.12 of K&R2.
    >
    >
    > Two quotes from there:
    >
    > "printf("%d %d\n", ++n, power(2, n)); /* WRONG */"
    >
    >
    > "One unhappy situation is typified by the statement
    >
    > a= i++;"


    Well these examples are different from what you have shown above. The
    first example above invokes unspecified behaviour while the second one
    invokes undefined behaviour. The example in your first post does
    neither as far as I can see.
     
    santosh, Mar 28, 2008
    #6
  7. Ioannis Vranos

    Ian Collins Guest

    Ioannis Vranos wrote:
    > Eric Sosman wrote:
    >> Ioannis Vranos wrote:
    >>> AFAIK the following is implementation-defined behaviour, am I right?:
    >>>
    >>>
    >>> #include <stdio.h>
    >>>
    >>>
    >>> int main(void)
    >>> {
    >>> int n= 0;
    >>>
    >>> printf("%d\n", n++);
    >>>
    >>>
    >>> return 0;
    >>> }

    >> Only by quibbles: the form of "successful termination"
    >> returned to the host environment is implementation-defined,
    >> the actual new-line representation written to stdout in
    >> response to the '\n' is implementation-defined, and things
    >> of that sort.
    >>
    >> What aspect do you believe is not Standard-defined?

    >
    >
    > I am talking about the implementation-defined behaviour of the printf()
    > call described at 2.12 of K&R2.
    >

    There's nothing wrong with your example, the one you cite is completely
    different. If you had tried to use n again in the printf, you would hit UB.

    --
    Ian Collins.
     
    Ian Collins, Mar 28, 2008
    #7
  8. Ian Collins wrote:
    > Ioannis Vranos wrote:
    >> Eric Sosman wrote:
    >>> Ioannis Vranos wrote:
    >>>> AFAIK the following is implementation-defined behaviour, am I right?:
    >>>>
    >>>>
    >>>> #include <stdio.h>
    >>>>
    >>>>
    >>>> int main(void)
    >>>> {
    >>>> int n= 0;
    >>>>
    >>>> printf("%d\n", n++);
    >>>>
    >>>>
    >>>> return 0;
    >>>> }
    >>> Only by quibbles: the form of "successful termination"
    >>> returned to the host environment is implementation-defined,
    >>> the actual new-line representation written to stdout in
    >>> response to the '\n' is implementation-defined, and things
    >>> of that sort.
    >>>
    >>> What aspect do you believe is not Standard-defined?

    >>
    >> I am talking about the implementation-defined behaviour of the printf()
    >> call described at 2.12 of K&R2.
    >>

    > There's nothing wrong with your example, the one you cite is completely
    > different. If you had tried to use n again in the printf, you would hit UB.



    So, printf("%d "%d\n", x++, x++); invokes implementation-defined
    behaviour, while printf("%d\n", x++); doesn't invoke
    implementation-defined behaviour?
     
    Ioannis Vranos, Mar 28, 2008
    #8
  9. Ioannis Vranos

    Dann Corbit Guest

    "Ioannis Vranos" <> wrote in message
    news:fshjmg$1avp$...
    > AFAIK the following is implementation-defined behaviour, am I right?:
    >
    >
    > #include <stdio.h>
    >
    >
    > int main(void)
    > {
    > int n= 0;
    >
    > printf("%d\n", n++);
    >
    >
    > return 0;
    > }


    C:\tmp>lin foo.c

    C:\tmp>"C:\Lint\Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP) foo.c
    PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software 1985-2006

    --- Module: foo.c (C)

    C:\tmp>type _LINT.TMP | more

    --- Module: foo.c (C)
    _
    printf("%d %d\n", n++, n);
    foo.c(8) : Warning 564: variable 'n' depends on order of evaluation

    ---
    output placed in _LINT.TMP

    C:\tmp>splint foo.c
    Splint 3.1.1 --- 12 Mar 2007

    foo.c: (in function main)
    foo.c(8,24): Argument 2 modifies n, used by argument 3 (order of evaluation
    of
    actual parameters is undefined): printf("%d %d\n", n++, n)
    Code has unspecified behavior. Order of evaluation of function parameters
    or
    subexpressions is not defined, so if a value is used and modified in
    different places not separated by a sequence point constraining evaluation
    order, then the result of the expression is unspecified. (Use -evalorder
    to
    inhibit warning)

    Finished checking --- 1 code warning

    C:\tmp>type foo.c
    #include <stdio.h>
    int main(void)
    {
    int n = 0;
    /* Not a problem, function call is a sequence point: */
    printf("%d\n", n++);
    /* Problem here, order unspecified */
    printf("%d %d\n", n++, n);
    return 0;
    }



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Dann Corbit, Mar 28, 2008
    #9
  10. Ioannis Vranos

    Dann Corbit Guest

    "Ioannis Vranos" <> wrote in message
    news:fsho27$1o9d$...
    > Ian Collins wrote:
    >> Ioannis Vranos wrote:
    >>> Eric Sosman wrote:
    >>>> Ioannis Vranos wrote:
    >>>>> AFAIK the following is implementation-defined behaviour, am I right?:
    >>>>>
    >>>>>
    >>>>> #include <stdio.h>
    >>>>>
    >>>>>
    >>>>> int main(void)
    >>>>> {
    >>>>> int n= 0;
    >>>>>
    >>>>> printf("%d\n", n++);
    >>>>>
    >>>>>
    >>>>> return 0;
    >>>>> }
    >>>> Only by quibbles: the form of "successful termination"
    >>>> returned to the host environment is implementation-defined,
    >>>> the actual new-line representation written to stdout in
    >>>> response to the '\n' is implementation-defined, and things
    >>>> of that sort.
    >>>>
    >>>> What aspect do you believe is not Standard-defined?
    >>>
    >>> I am talking about the implementation-defined behaviour of the printf()
    >>> call described at 2.12 of K&R2.
    >>>

    >> There's nothing wrong with your example, the one you cite is completely
    >> different. If you had tried to use n again in the printf, you would hit
    >> UB.

    >
    >
    > So, printf("%d %d\n", x++, x++); invokes implementation-defined

    so does:
    printf("%d %d\n", x++, x);

    > behaviour, while printf("%d\n", x++); doesn't invoke
    > implementation-defined behaviour?


    This one does not.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Dann Corbit, Mar 28, 2008
    #10
  11. Ioannis Vranos wrote:
    > So, printf("%d "%d\n", x++, x++); invokes implementation-defined
    > behaviour, while printf("%d\n", x++); doesn't invoke
    > implementation-defined behaviour?


    'printf("%d "%d\n", x++, x++)' invokes _undefined_ behavior. 'printf("%d
    "%d\n", x++, x)' also invokes _undefined_ behavior.

    'printf("%d\n", x++)' does not invoke undefined behavior.

    "Implementation-defined behavior" is not immediately relevant to the
    nature of your question.

    --
    Best regards,
    Andrey Tarasevich
     
    Andrey Tarasevich, Mar 28, 2008
    #11
  12. On Fri, 28 Mar 2008 05:18:31 +0200, Ioannis Vranos
    <> wrote:

    >Ian Collins wrote:
    >> Ioannis Vranos wrote:
    >>> Eric Sosman wrote:
    >>>> Ioannis Vranos wrote:
    >>>>> AFAIK the following is implementation-defined behaviour, am I right?:
    >>>>>
    >>>>>
    >>>>> #include <stdio.h>
    >>>>>
    >>>>>
    >>>>> int main(void)
    >>>>> {
    >>>>> int n= 0;
    >>>>>
    >>>>> printf("%d\n", n++);
    >>>>>
    >>>>>
    >>>>> return 0;
    >>>>> }
    >>>> Only by quibbles: the form of "successful termination"
    >>>> returned to the host environment is implementation-defined,
    >>>> the actual new-line representation written to stdout in
    >>>> response to the '\n' is implementation-defined, and things
    >>>> of that sort.
    >>>>
    >>>> What aspect do you believe is not Standard-defined?
    >>>
    >>> I am talking about the implementation-defined behaviour of the printf()
    >>> call described at 2.12 of K&R2.
    >>>

    >> There's nothing wrong with your example, the one you cite is completely
    >> different. If you had tried to use n again in the printf, you would hit UB.

    >
    >
    >So, printf("%d "%d\n", x++, x++); invokes implementation-defined


    This invokes undefined behavior. The commas separating function
    arguments are not sequence points. You are modifying x twice without
    an intervening sequence point.

    >behaviour, while printf("%d\n", x++); doesn't invoke
    >implementation-defined behaviour?



    Remove del for email
     
    Barry Schwarz, Mar 28, 2008
    #12
  13. On Thu, 27 Mar 2008 20:19:35 -0700, "Dann Corbit" <>
    wrote:

    >"Ioannis Vranos" <> wrote in message
    >news:fshjmg$1avp$...
    >> AFAIK the following is implementation-defined behaviour, am I right?:
    >>
    >>
    >> #include <stdio.h>
    >>
    >>
    >> int main(void)
    >> {
    >> int n= 0;
    >>
    >> printf("%d\n", n++);
    >>
    >>
    >> return 0;
    >> }

    >
    >C:\tmp>lin foo.c
    >
    >C:\tmp>"C:\Lint\Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP) foo.c
    >PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software 1985-2006
    >
    >--- Module: foo.c (C)
    >
    >C:\tmp>type _LINT.TMP | more
    >
    >--- Module: foo.c (C)
    > _
    > printf("%d %d\n", n++, n);
    >foo.c(8) : Warning 564: variable 'n' depends on order of evaluation


    The correct diagnostic would state: without an intervening sequence
    point, n is modified and also evaluated for a purpose other than
    determining the modified value. This invokes undefined behavior.

    >
    >---
    > output placed in _LINT.TMP
    >
    >C:\tmp>splint foo.c
    >Splint 3.1.1 --- 12 Mar 2007
    >
    >foo.c: (in function main)
    >foo.c(8,24): Argument 2 modifies n, used by argument 3 (order of evaluation
    >of
    > actual parameters is undefined): printf("%d %d\n", n++, n)
    > Code has unspecified behavior. Order of evaluation of function parameters
    >or
    > subexpressions is not defined, so if a value is used and modified in
    > different places not separated by a sequence point constraining evaluation
    > order, then the result of the expression is unspecified. (Use -evalorder
    >to
    > inhibit warning)
    >
    >Finished checking --- 1 code warning
    >
    >C:\tmp>type foo.c
    >#include <stdio.h>
    >int main(void)
    >{
    > int n = 0;
    > /* Not a problem, function call is a sequence point: */
    > printf("%d\n", n++);
    > /* Problem here, order unspecified */
    > printf("%d %d\n", n++, n);
    > return 0;
    >}



    Remove del for email
     
    Barry Schwarz, Mar 28, 2008
    #13
  14. Ioannis Vranos

    Dann Corbit Guest

    "Barry Schwarz" <> wrote in message
    news:...
    > On Thu, 27 Mar 2008 20:19:35 -0700, "Dann Corbit" <>
    > wrote:
    >
    >>"Ioannis Vranos" <> wrote in message
    >>news:fshjmg$1avp$...
    >>> AFAIK the following is implementation-defined behaviour, am I right?:
    >>>
    >>>
    >>> #include <stdio.h>
    >>>
    >>>
    >>> int main(void)
    >>> {
    >>> int n= 0;
    >>>
    >>> printf("%d\n", n++);
    >>>
    >>>
    >>> return 0;
    >>> }

    >>
    >>C:\tmp>lin foo.c
    >>
    >>C:\tmp>"C:\Lint\Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP) foo.c
    >>PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software 1985-2006
    >>
    >>--- Module: foo.c (C)
    >>
    >>C:\tmp>type _LINT.TMP | more
    >>
    >>--- Module: foo.c (C)
    >> _
    >> printf("%d %d\n", n++, n);
    >>foo.c(8) : Warning 564: variable 'n' depends on order of evaluation

    >
    > The correct diagnostic would state: without an intervening sequence
    > point, n is modified and also evaluated for a purpose other than
    > determining the modified value. This invokes undefined behavior.


    The examination of n in the last parameter of printf() is to determine its
    value.
    I am not sure that your interpretation is certain. Are you sure of it?



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Dann Corbit, Mar 28, 2008
    #14
  15. Dann Corbit said:

    > "Barry Schwarz" <> wrote in message
    > news:...

    <snip>
    >>> printf("%d %d\n", n++, n);
    >>>foo.c(8) : Warning 564: variable 'n' depends on order of evaluation

    >>
    >> The correct diagnostic would state: without an intervening sequence
    >> point, n is modified and also evaluated for a purpose other than
    >> determining the modified value. This invokes undefined behavior.

    >
    > The examination of n in the last parameter of printf() is to determine
    > its value.


    More to the point, it is /not/ to determine the /modified/ value.

    > I am not sure that your interpretation is certain. Are you sure of it?


    If he isn't, he should be.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Mar 28, 2008
    #15
  16. Ioannis Vranos

    Dann Corbit Guest

    "Richard Heathfield" <> wrote in message
    news:...
    > Dann Corbit said:
    >
    >> "Barry Schwarz" <> wrote in message
    >> news:...

    > <snip>
    >>>> printf("%d %d\n", n++, n);
    >>>>foo.c(8) : Warning 564: variable 'n' depends on order of evaluation
    >>>
    >>> The correct diagnostic would state: without an intervening sequence
    >>> point, n is modified and also evaluated for a purpose other than
    >>> determining the modified value. This invokes undefined behavior.

    >>
    >> The examination of n in the last parameter of printf() is to determine
    >> its value.

    >
    > More to the point, it is /not/ to determine the /modified/ value.


    How about:
    printf("%d %d\n", ++n, n);

    In this case one could possibly argue that the intent is to determine the
    modified value.

    >> I am not sure that your interpretation is certain. Are you sure of it?

    >
    > If he isn't, he should be.


    While I agree it is an awful construct, I think that 'purpose' renders the
    statement a bit ambiguous, because it implies intent.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Dann Corbit, Mar 28, 2008
    #16
  17. Dann Corbit said:

    <snip>
    >
    > How about:
    > printf("%d %d\n", ++n, n);
    >
    > In this case one could possibly argue that the intent is to determine the
    > modified value.


    The intent might be. Nevertheless, the *purpose* is not (because the order
    of evaluation of function arguments is unspecified).

    > While I agree it is an awful construct, I think that 'purpose' renders
    > the statement a bit ambiguous, because it implies intent.


    I don't think so, actually. Intent implies the possibility of mistaken
    execution of that intent, which would in turn require the implementation
    to read minds! No: *irrespective* of the intent, the *purpose* cannot be
    to determine the modified value, in either the "%d %d\n", ++n, n or the
    "%d %d\n", n, ++n case, because in neither case is the evaluation order
    specified.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Mar 28, 2008
    #17
  18. Ioannis Vranos

    Dann Corbit Guest

    "Richard Heathfield" <> wrote in message
    news:...
    > Dann Corbit said:
    >
    > <snip>
    >>
    >> How about:
    >> printf("%d %d\n", ++n, n);
    >>
    >> In this case one could possibly argue that the intent is to determine the
    >> modified value.

    >
    > The intent might be. Nevertheless, the *purpose* is not (because the order
    > of evaluation of function arguments is unspecified).
    >
    >> While I agree it is an awful construct, I think that 'purpose' renders
    >> the statement a bit ambiguous, because it implies intent.

    >
    > I don't think so, actually. Intent implies the possibility of mistaken
    > execution of that intent, which would in turn require the implementation
    > to read minds! No: *irrespective* of the intent, the *purpose* cannot be
    > to determine the modified value, in either the "%d %d\n", ++n, n or the
    > "%d %d\n", n, ++n case, because in neither case is the evaluation order
    > specified.


    I'm convinced.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Dann Corbit, Mar 28, 2008
    #18
  19. Ioannis Vranos wrote:
    > So, printf("%d "%d\n", x++, x++); invokes implementation-defined
    > behaviour, while printf("%d\n", x++); doesn't invoke
    > implementation-defined behaviour?
    >

    Aside from the fact that this won't compile (you have one too many "
    characters), this is almost exactly the same question as FAQ 3.2. The
    problem is not the individual 'x++' expressions, but the way they
    interact with each other.

    Philip
     
    Philip Potter, Mar 28, 2008
    #19
  20. Andrey Tarasevich wrote:
    > Ioannis Vranos wrote:
    >> So, printf("%d "%d\n", x++, x++); invokes implementation-defined
    >> behaviour, while printf("%d\n", x++); doesn't invoke
    >> implementation-defined behaviour?

    >
    > 'printf("%d "%d\n", x++, x++)' invokes _undefined_ behavior. 'printf("%d
    > "%d\n", x++, x)' also invokes _undefined_ behavior.
    >
    > 'printf("%d\n", x++)' does not invoke undefined behavior.
    >
    > "Implementation-defined behavior" is not immediately relevant to the
    > nature of your question.



    K&R2 mentions the following:

    "printf("%d %d\n", ++n, power(2,n)); /* WRONG */

    can produce different results with different compilers, depending on
    whether n is incremented before power is called".


    That's why I call it implementation-defined behaviour.
     
    Ioannis Vranos, Mar 28, 2008
    #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. Enrico `Trippo' Porreca

    Line input and implementation-defined behaviour

    Enrico `Trippo' Porreca, Sep 27, 2003, in forum: C Programming
    Replies:
    29
    Views:
    688
    Kevin Easton
    Oct 2, 2003
  2. Oodini
    Replies:
    1
    Views:
    1,822
    Keith Thompson
    Sep 27, 2005
  3. Angel Tsankov
    Replies:
    1
    Views:
    885
    Victor Bazarov
    Apr 5, 2006
  4. Michael Tsang
    Replies:
    32
    Views:
    1,150
    Richard Bos
    Mar 1, 2010
  5. Michael Tsang
    Replies:
    54
    Views:
    1,228
    Phil Carmody
    Mar 30, 2010
Loading...

Share This Page