Eventual undefined behaviour

Discussion in 'C Programming' started by Spiros Bousbouras, Sep 14, 2007.

  1. #include <stdio.h>

    int main(void) {
    int i ;

    for (i=1 ; i != 0 ; i++) ;
    printf("Finished !\n") ;
    return 0 ;
    }

    Assume that a compiler is clever enough to realise that the
    above will eventually overflow i. Can it refuse to produce an
    executable on that basis ?
     
    Spiros Bousbouras, Sep 14, 2007
    #1
    1. Advertising

  2. Spiros Bousbouras

    Ravi Guest

    > Assume that a compiler is clever enough to realise that the
    > above will eventually overflow i. Can it refuse to produce an
    > executable on that basis ?


    It won't. Eventually i will become -ve after reaching it +ve maximum
    and then it will become 0. So it will terminate.
    Hurray!
     
    Ravi, Sep 14, 2007
    #2
    1. Advertising

  3. In article <>,
    Ravi <> wrote:

    >It won't. Eventually i will become -ve after reaching it +ve maximum
    >and then it will become 0. So it will terminate.


    On most machines, but it's not guaranteed.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Sep 14, 2007
    #3
  4. On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
    > #include <stdio.h>
    >
    > int main(void) {
    > int i ;
    >
    > for (i=1 ; i != 0 ; i++) ;
    > printf("Finished !\n") ;
    > return 0 ;
    > }
    >
    > Assume that a compiler is clever enough to realise that the above will
    > eventually overflow i. Can it refuse to produce an executable on that
    > basis ?


    Yes, but only because it can be proven that the loop will always execute.
    If the function were named differently, and the compiler could no longer
    prove it would be called unconditionally, then the compiler would have to
    accept the code.
     
    =?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=, Sep 14, 2007
    #4
  5. "Harald van D?k" <> a écrit dans le message de news:
    fcecig$2a9$1.ov.home.nl...
    > On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
    >> #include <stdio.h>
    >>
    >> int main(void) {
    >> int i ;
    >>
    >> for (i=1 ; i != 0 ; i++) ;
    >> printf("Finished !\n") ;
    >> return 0 ;
    >> }
    >>
    >> Assume that a compiler is clever enough to realise that the above will
    >> eventually overflow i. Can it refuse to produce an executable on that
    >> basis ?

    >
    > Yes, but only because it can be proven that the loop will always execute.
    > If the function were named differently, and the compiler could no longer
    > prove it would be called unconditionally, then the compiler would have to
    > accept the code.


    if i was defined as an unsigned variable, the behaviour is well defined and
    I see no reason for the compiler to complain. If it is smart enough, it
    will optimize to loop away.

    With i as an int, it depends on the implementation whether the behaviour is
    undefined or not. The compiler could detect the inevitable integer overflow
    and complain about it, or even refuse to produce an executable, but on most
    architectures the behaviour is defined and the loop can be optimized away.

    --
    Chqrlie.
     
    Charlie Gordon, Sep 14, 2007
    #5
  6. On Fri, 14 Sep 2007 19:31:09 +0200, Charlie Gordon wrote:
    > "Harald van D?k" <> a écrit dans le message de news:
    > fcecig$2a9$1.ov.home.nl...
    >> On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
    >>> int i ;
    >>>
    >>> for (i=1 ; i != 0 ; i++) ;

    >
    > With i as an int, it depends on the implementation whether the behaviour
    > is undefined or not. The compiler could detect the inevitable integer
    > overflow and complain about it, or even refuse to produce an executable,
    > but on most architectures the behaviour is defined and the loop can be
    > optimized away.


    Implementations are allowed to define the behaviour on signed integer
    overflow as an extension, but as far as I'm aware, most don't. If you try
    it, usually, you'll see the wraparound you probably expect, but you
    shouldn't rely on it unless it's documented, or your code may well end up
    broken for newer versions of the compiler. This happened quite a bit with
    GCC 4.2, and will probably occur again with different versions or
    different compilers.
     
    =?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F, Sep 14, 2007
    #6
  7. Spiros Bousbouras

    CBFalconer Guest

    Ravi wrote:
    >
    >> Assume that a compiler is clever enough to realise that the
    >> above will eventually overflow i. Can it refuse to produce an
    >> executable on that basis ?

    >
    > It won't. Eventually i will become -ve after reaching it +ve
    > maximum and then it will become 0. So it will terminate.


    The above *erroneous* statement needs rapid stomping. In C, any
    integer overflow results in undefined behaviour. Some systems may
    resolve that to resolving to a negative value, but even then which
    value is variable (think 1's and 2's complement arithmetic). If
    you want to handle overflow consistently, used unsigned integers,
    which do modulo arithmetic.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Sep 14, 2007
    #7
  8. "Harald van D?k" <> a écrit dans le message de news:
    fcemg2$ruk$1.ov.home.nl...
    > On Fri, 14 Sep 2007 19:31:09 +0200, Charlie Gordon wrote:
    >> "Harald van D?k" <> a écrit dans le message de news:
    >> fcecig$2a9$1.ov.home.nl...
    >>> On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
    >>>> int i ;
    >>>>
    >>>> for (i=1 ; i != 0 ; i++) ;

    >>
    >> With i as an int, it depends on the implementation whether the behaviour
    >> is undefined or not. The compiler could detect the inevitable integer
    >> overflow and complain about it, or even refuse to produce an executable,
    >> but on most architectures the behaviour is defined and the loop can be
    >> optimized away.

    >
    > Implementations are allowed to define the behaviour on signed integer
    > overflow as an extension, but as far as I'm aware, most don't. If you try
    > it, usually, you'll see the wraparound you probably expect, but you
    > shouldn't rely on it unless it's documented, or your code may well end up
    > broken for newer versions of the compiler. This happened quite a bit with
    > GCC 4.2, and will probably occur again with different versions or
    > different compilers.


    Come on, what gcc target does not do simple wrap around on signed integer
    overflow ?

    --
    Chqrlie.
     
    Charlie Gordon, Sep 14, 2007
    #8
  9. Spiros Bousbouras

    CBFalconer Guest

    Charlie Gordon wrote:
    >

    .... snip ...
    >
    > Come on, what gcc target does not do simple wrap around on signed
    > integer overflow ?


    At least any that implement overflow traps. I can set up the 8088
    to do just that.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Sep 15, 2007
    #9
  10. Spiros Bousbouras

    Flash Gordon Guest

    CBFalconer wrote, On 14/09/07 20:19:
    > Ravi wrote:
    >>> Assume that a compiler is clever enough to realise that the
    >>> above will eventually overflow i. Can it refuse to produce an
    >>> executable on that basis ?

    >> It won't. Eventually i will become -ve after reaching it +ve
    >> maximum and then it will become 0. So it will terminate.

    >
    > The above *erroneous* statement needs rapid stomping. In C, any
    > integer overflow results in undefined behaviour. Some systems may
    > resolve that to resolving to a negative value, but even then which
    > value is variable (think 1's and 2's complement arithmetic). If
    > you want to handle overflow consistently, used unsigned integers,
    > which do modulo arithmetic.


    Note that some processors (the ones I know are DSPs have the ability to
    limit at maximum +ve/-ve. So a loop of the form
    for (i=1 ; i != 0 ; i++) ;
    Would actually loop forever if the processor was put in that mode.
    --
    Flash Gordon
     
    Flash Gordon, Sep 15, 2007
    #10
  11. "CBFalconer" <> a écrit dans le message de news:
    ...
    > Charlie Gordon wrote:
    >>

    > ... snip ...
    >>
    >> Come on, what gcc target does not do simple wrap around on signed
    >> integer overflow ?

    >
    > At least any that implement overflow traps. I can set up the 8088
    > to do just that.


    Yes, but do you have an OS or even a program that runs in this mode ?

    --
    Chqrlie.
     
    Charlie Gordon, Sep 15, 2007
    #11
  12. On Sat, 15 Sep 2007 00:43:23 +0200, Charlie Gordon wrote:
    > "Harald van D?k" <> a écrit dans le message de news:
    > fcemg2$ruk$1.ov.home.nl...
    >> Implementations are allowed to define the behaviour on signed integer
    >> overflow as an extension, but as far as I'm aware, most don't. If you
    >> try it, usually, you'll see the wraparound you probably expect, but you
    >> shouldn't rely on it unless it's documented, or your code may well end
    >> up broken for newer versions of the compiler. This happened quite a bit
    >> with GCC 4.2, and will probably occur again with different versions or
    >> different compilers.

    >
    > Come on, what gcc target does not do simple wrap around on signed
    > integer overflow ?


    All of them, regardless of the behaviour of the underlying hardware. The
    standard allows

    int f(int x) {
    return x + 1 > x;
    }

    to be optimised to

    int f(int x) {
    return 1;
    }

    and gcc does exactly that.
     
    =?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F, Sep 15, 2007
    #12
  13. Spiros Bousbouras

    Jack Klein Guest

    On Fri, 14 Sep 2007 19:31:09 +0200, "Charlie Gordon"
    <> wrote in comp.lang.c:

    > "Harald van D?k" <> a écrit dans le message de news:
    > fcecig$2a9$1.ov.home.nl...
    > > On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
    > >> #include <stdio.h>
    > >>
    > >> int main(void) {
    > >> int i ;
    > >>
    > >> for (i=1 ; i != 0 ; i++) ;
    > >> printf("Finished !\n") ;
    > >> return 0 ;
    > >> }
    > >>
    > >> Assume that a compiler is clever enough to realise that the above will
    > >> eventually overflow i. Can it refuse to produce an executable on that
    > >> basis ?

    > >
    > > Yes, but only because it can be proven that the loop will always execute.
    > > If the function were named differently, and the compiler could no longer
    > > prove it would be called unconditionally, then the compiler would have to
    > > accept the code.

    >
    > if i was defined as an unsigned variable, the behaviour is well defined and
    > I see no reason for the compiler to complain. If it is smart enough, it
    > will optimize to loop away.
    >
    > With i as an int, it depends on the implementation whether the behaviour is
    > undefined or not. The compiler could detect the inevitable integer overflow


    Signed integer overflow or underflow is always undefined.

    > and complain about it, or even refuse to produce an executable, but on most
    > architectures the behaviour is defined and the loop can be optimized away.


    No, in C it is always undefined behavior. The result may be
    predictable and repeatable on a particular platform, but that doesn't
    make it defined.

    Predictable and repeatable results are one possible consequence of
    undefined behavior.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Sep 15, 2007
    #13
  14. On 15 Sep, 00:47, Flash Gordon <> wrote:
    > Note that some processors (the ones I know are DSPs have the ability to
    > limit at maximum +ve/-ve.


    What does "ve" mean ? Neither dictionary.com nor
    acronymfinder.com gave me a definition which makes
    sense in this context.

    outOfTopic {
    What does it mean for a DSP to "limit" ? I've
    never seen "limit" being used as an intransitive
    verb.
    }
     
    Spiros Bousbouras, Sep 15, 2007
    #14
  15. Spiros Bousbouras

    CBFalconer Guest

    Charlie Gordon wrote:
    > "CBFalconer" <> a écrit:
    >> Charlie Gordon wrote:
    >>>

    >> ... snip ...
    >>>
    >>> Come on, what gcc target does not do simple wrap around on signed
    >>> integer overflow ?

    >>
    >> At least any that implement overflow traps. I can set up the 8088
    >> to do just that.

    >
    > Yes, but do you have an OS or even a program that runs in this mode ?


    Yes.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Sep 15, 2007
    #15
  16. "CBFalconer" <> a écrit dans le message de news:
    ...
    > Charlie Gordon wrote:
    >> "CBFalconer" <> a écrit:
    >>> Charlie Gordon wrote:
    >>>>
    >>> ... snip ...
    >>>>
    >>>> Come on, what gcc target does not do simple wrap around on signed
    >>>> integer overflow ?
    >>>
    >>> At least any that implement overflow traps. I can set up the 8088
    >>> to do just that.

    >>
    >> Yes, but do you have an OS or even a program that runs in this mode ?

    >
    > Yes.


    I'm impressed !
    We should call that a DS8088

    --
    Chqrlie.
     
    Charlie Gordon, Sep 15, 2007
    #16
  17. CBFalconer wrote:

    > Charlie Gordon wrote:
    >>

    > ... snip ...
    >>
    >> Come on, what gcc target does not do simple wrap around on signed
    >> integer overflow ?

    >
    > At least any that implement overflow traps. I can set up the 8088
    > to do just that.
    >

    Or any target that has saturation arithmetic (the value is clipped in
    the range of representable values).
    Not all the world is a VAX!

    Bart v Ingen Schenau
    --
    a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
    c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    c.l.c++ FAQ: http://www.parashift.com/c -faq-lite/
     
    Bart van Ingen Schenau, Sep 15, 2007
    #17
  18. Spiros Bousbouras

    Flash Gordon Guest

    Spiros Bousbouras wrote, On 15/09/07 14:23:
    > On 15 Sep, 00:47, Flash Gordon <> wrote:
    >> Note that some processors (the ones I know are DSPs have the ability to
    >> limit at maximum +ve/-ve.

    >
    > What does "ve" mean ? Neither dictionary.com nor
    > acronymfinder.com gave me a definition which makes
    > sense in this context.


    +ve is a fairly well known abbreviation for positive in England and I
    suspect a number of other countries. I'll let you work out what -ve is.

    > outOfTopic {
    > What does it mean for a DSP to "limit" ? I've
    > never seen "limit" being used as an intransitive
    > verb.
    > }


    With a 16 bit int
    i = 0x7FFF;
    i++; /* i is *still* 0x7FFF */
    --
    Flash Gordon
     
    Flash Gordon, Sep 15, 2007
    #18
  19. Spiros Bousbouras <> writes:
    > On 15 Sep, 00:47, Flash Gordon <> wrote:
    >> Note that some processors (the ones I know are DSPs have the ability to
    >> limit at maximum +ve/-ve.

    >
    > What does "ve" mean ? Neither dictionary.com nor
    > acronymfinder.com gave me a definition which makes
    > sense in this context.


    "+ve" means "positive", "-ve" means "negative".

    > outOfTopic {
    > What does it mean for a DSP to "limit" ? I've
    > never seen "limit" being used as an intransitive
    > verb.
    > }


    I think it refers to saturation, meaning that a computation that
    overflows yields an extreme value of the type. For example, INT_MAX +
    1 would yield INT_MAX; INT_MIN * 3 would yield INT_MIN.

    --
    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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 15, 2007
    #19
  20. Spiros Bousbouras wrote:

    > On 15 Sep, 00:47, Flash Gordon <> wrote:
    >> Note that some processors (the ones I know are DSPs have the ability
    >> to limit at maximum +ve/-ve.

    >
    > What does "ve" mean ? Neither dictionary.com nor
    > acronymfinder.com gave me a definition which makes
    > sense in this context.


    +ve is shorthand for 'positive'. -ve is shorthand for 'negative'.
    The sign in front of the ve is significant here.

    >
    > outOfTopic {
    > What does it mean for a DSP to "limit" ? I've
    > never seen "limit" being used as an intransitive
    > verb.
    > }


    It is also known a saturating arithmetic.
    With saturating arithmetic, the following holds:
    int foo = INT_MAX;
    foo++;
    assert(foo == INT_MAX);
    (and similar for decrement of lowest value).

    Bart v Ingen Schenau
    --
    a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
    c.l.c FAQ: http://c-faq.com/
    c.l.c++ FAQ: http://www.parashift.com/c -faq-lite/
     
    Bart van Ingen Schenau, Sep 15, 2007
    #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. Dan Cernat

    undefined behaviour

    Dan Cernat, Nov 11, 2003, in forum: C++
    Replies:
    1
    Views:
    345
    Josh Sebastian
    Nov 11, 2003
  2. marbac

    Undefined behaviour

    marbac, Jul 13, 2004, in forum: C++
    Replies:
    48
    Views:
    1,341
    Default User
    Jul 20, 2004
  3. Mantorok Redgormor
    Replies:
    70
    Views:
    1,759
    Dan Pop
    Feb 17, 2004
  4. VK
    Replies:
    45
    Views:
    602
    Dr John Stockton
    Sep 12, 2006
  5. -Lost
    Replies:
    13
    Views:
    372
    Richard Cornford
    Jan 31, 2007
Loading...

Share This Page