undefined behavior?

Discussion in 'C Programming' started by Loic Domaigne, Oct 29, 2007.

  1. Hello everybody,

    Let's assume that I have the following prototype:
    void myf(int x, ...) ;

    The function myf() is then called as follows:

    int i=0;
    f(a[i++],a[i++]); // a is an array

    This sounds to me like an undefined behavior, am I right?

    Thanks in advance,
    Loic.
    --
     
    Loic Domaigne, Oct 29, 2007
    #1
    1. Advertising

  2. Loic Domaigne

    Guest

    On Oct 29, 3:34 pm, Loic Domaigne <> wrote:
    > Hello everybody,
    >
    > Let's assume that I have the following prototype:
    > void myf(int x, ...) ;
    >
    > The function myf() is then called as follows:
    >
    > int i=0;
    > f(a[i++],a[i++]); // a is an array
    >
    > This sounds to me like an undefined behavior, am I right?
    >
    > Thanks in advance,
    > Loic.
    > --


    yes , order of evaluation in function parameters is compiler dependent
     
    , Oct 29, 2007
    #2
    1. Advertising

  3. Loic Domaigne

    Richard Bos Guest

    "" <> wrote:

    > On Oct 29, 3:34 pm, Loic Domaigne <> wrote:
    > > Let's assume that I have the following prototype:
    > > void myf(int x, ...) ;
    > >
    > > The function myf() is then called as follows:
    > >
    > > int i=0;
    > > f(a[i++],a[i++]); // a is an array
    > >
    > > This sounds to me like an undefined behavior, am I right?

    >
    > yes , order of evaluation in function parameters is compiler dependent


    It's worse than that. It's not just implementation-defined behaviour,
    it's full-blown _un_-defined behaviour. If it only depended on the order
    of evaluation, you'd have two possible outcomes: one way 'round, or the
    other way 'round. But it's undefined, so anything may happen, from what
    the naive programmer believes "should" happen to a complete crash, and
    worse.
    The prototype of the function doesn't matter here, BTW. You modify the
    value of i twice between sequence points. _That_ causes UB, no matter
    what else.

    Richard
     
    Richard Bos, Oct 29, 2007
    #3
  4. "Richard Bos" <> schrieb im Newsbeitrag
    news:4all.nl...
    > "" <> wrote:
    >
    >> On Oct 29, 3:34 pm, Loic Domaigne <> wrote:
    >> > Let's assume that I have the following prototype:
    >> > void myf(int x, ...) ;
    >> >
    >> > The function myf() is then called as follows:
    >> >
    >> > int i=0;
    >> > f(a[i++],a[i++]); // a is an array
    >> >
    >> > This sounds to me like an undefined behavior, am I right?

    >>
    >> yes , order of evaluation in function parameters is compiler dependent

    >
    > It's worse than that. It's not just implementation-defined behaviour,
    > it's full-blown _un_-defined behaviour. If it only depended on the order
    > of evaluation, you'd have two possible outcomes: one way 'round, or the
    > other way 'round. But it's undefined, so anything may happen, from what
    > the naive programmer believes "should" happen to a complete crash, and
    > worse.
    > The prototype of the function doesn't matter here, BTW. You modify the
    > value of i twice between sequence points. _That_ causes UB, no matter
    > what else.

    the comma doesn't act as a sequence point here inside an argument list, like
    is otherwise would?

    Bye, Jojo
     
    Joachim Schmitz, Oct 29, 2007
    #4
  5. Loic Domaigne

    Richard Bos Guest

    "Joachim Schmitz" <> wrote:

    > "Richard Bos" <> schrieb im Newsbeitrag
    > > "" <> wrote:
    > >
    > >> On Oct 29, 3:34 pm, Loic Domaigne <> wrote:
    > >> > Let's assume that I have the following prototype:
    > >> > void myf(int x, ...) ;
    > >> >
    > >> > The function myf() is then called as follows:
    > >> >
    > >> > int i=0;
    > >> > f(a[i++],a[i++]); // a is an array
    > >> >
    > >> > This sounds to me like an undefined behavior, am I right?
    > >>
    > >> yes , order of evaluation in function parameters is compiler dependent

    > >
    > > It's worse than that. It's not just implementation-defined behaviour,
    > > it's full-blown _un_-defined behaviour. If it only depended on the order
    > > of evaluation, you'd have two possible outcomes: one way 'round, or the
    > > other way 'round. But it's undefined, so anything may happen, from what
    > > the naive programmer believes "should" happen to a complete crash, and
    > > worse.
    > > The prototype of the function doesn't matter here, BTW. You modify the
    > > value of i twice between sequence points. _That_ causes UB, no matter
    > > what else.

    > the comma doesn't act as a sequence point here inside an argument list, like
    > is otherwise would?


    The comma only introduces a sequence point when it's the comma
    _operator_. These are separators, a different part of the grammar
    entirely. So are the commas in, for example, this declaration:

    int i,j, *ip, ia[14];

    Richard
     
    Richard Bos, Oct 29, 2007
    #5
  6. Loic Domaigne

    santosh Guest

    Joachim Schmitz wrote:

    >
    > "Richard Bos" <> schrieb im Newsbeitrag
    > news:4all.nl...
    >> "" <> wrote:
    >>
    >>> On Oct 29, 3:34 pm, Loic Domaigne <> wrote:
    >>> > Let's assume that I have the following prototype:
    >>> > void myf(int x, ...) ;
    >>> >
    >>> > The function myf() is then called as follows:
    >>> >
    >>> > int i=0;
    >>> > f(a[i++],a[i++]); // a is an array
    >>> >
    >>> > This sounds to me like an undefined behavior, am I right?
    >>>
    >>> yes , order of evaluation in function parameters is compiler
    >>> dependent

    >>
    >> It's worse than that. It's not just implementation-defined behaviour,
    >> it's full-blown _un_-defined behaviour. If it only depended on the
    >> order of evaluation, you'd have two possible outcomes: one way
    >> 'round, or the other way 'round. But it's undefined, so anything may
    >> happen, from what the naive programmer believes "should" happen to a
    >> complete crash, and worse.
    >> The prototype of the function doesn't matter here, BTW. You modify
    >> the value of i twice between sequence points. _That_ causes UB, no
    >> matter what else.

    > the comma doesn't act as a sequence point here inside an argument
    > list, like is otherwise would?


    No.
     
    santosh, Oct 29, 2007
    #6
  7. On 29 Okt., 11:34, Loic Domaigne <> wrote:
    > Hello everybody,
    >
    > Let's assume that I have the following prototype:
    > void myf(int x, ...) ;
    >
    > The function myf() is then called as follows:
    >
    > int i=0;
    > f(a[i++],a[i++]); // a is an array
    >
    > This sounds to me like an undefined behavior, am I right?
    >
    > Thanks in advance,
    > Loic.
    > --


    Thanks everybody for your answers.

    Cheers,
    Loic.
     
    Loic Domaigne, Oct 29, 2007
    #7
  8. On Mon, 29 Oct 2007 11:30:29 GMT, (Richard
    Bos) wrote:

    > "Joachim Schmitz" <> wrote:


    > > >> > f(a[i++],a[i++]); // a is an array


    > > the comma doesn't act as a sequence point here inside an argument list, like
    > > is otherwise would?

    >
    > The comma only introduces a sequence point when it's the comma
    > _operator_. These are separators, a different part of the grammar
    > entirely. So are the commas in, for example, this declaration:
    >
    > int i,j, *ip, ia[14];
    >

    (Both) true as stated. However, a 'toplevel' comma in a declaration
    coincides with either the end of a full-declarator (as here) or of an
    initializer, and either of those IS a sequence point.

    - formerly david.thompson1 || achar(64) || worldnet.att.net
     
    David Thompson, Nov 12, 2007
    #8
    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. aka
    Replies:
    10
    Views:
    746
  2. REH
    Replies:
    25
    Views:
    857
    Victor Bazarov
    Mar 29, 2005
  3. Mantorok Redgormor
    Replies:
    70
    Views:
    1,843
    Dan Pop
    Feb 17, 2004
  4. VK
    Replies:
    45
    Views:
    665
    Dr John Stockton
    Sep 12, 2006
  5. -Lost
    Replies:
    13
    Views:
    390
    Richard Cornford
    Jan 31, 2007
Loading...

Share This Page