Re: Linux X demo

Discussion in 'C Programming' started by santosh, Jul 20, 2007.

  1. santosh

    santosh Guest

    On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <>
    wrote in message <>:

    > santosh wrote:
    >> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <>

    >
    >> > There is only one real warning:
    >> >
    >> >> windela.c:5611: warning: operation on ?j? may be undefined
    >> >
    >> > But this shouldn't be flaged as a warning but as an error.
    >> >
    >> > case 0x05: {la[--j] = la[j] / la[j+1]; break;}

    >>
    >> Why should this be an error? This exhibits undefined behaviour,
    >> but that doesn't mean compilation should be stopped.

    >
    > I don't care whether the compilation stops or not. But if the
    > behaviour of the generated code not only depends on the C source
    > code but also on the concrete implementation of the compiler, then
    > the source code is incorrect. And therefore an error and not a
    > warning has to be generated.


    That's what the Standard terms as Undefined behaviour, i.e. that the
    outcome of that construct is not defined by the rules of the
    Standard, and implementations are not required to define it either.
    Such a construct could produce different results between operating
    systems, between implementations, between compilations and even
    between two invocations of the program. *Nothing* is guaranteed, and
    the worst of it is that, once Undefined behaviour is invoked, the
    rest of the behaviour of your program also becomes undefined,
    (unless the construct that invoked undefined behaviour happened to
    be the very last action of your program).

    Conforming compilers are required to stop compilation only if an
    active #error preprocessor directive is encountered. Anything else
    *can* be successfully compiled, though a diagnostic is mandatory for
    each constraint violation.

    >> > With this code, Windela shouldn't work properly when compiled
    >> > with GCC on a SUN (but this was my first C program and you only
    >> > learn by making errors).

    >>
    >> Why only on the SUN? This code should invoke undefined behaviour
    >> on all implementations, since 'j' is modified more than once
    >> between sequence points.

    >
    > It doesn't invoke undefined behaviour but a compiler dependent
    > behaviour.


    AFAIK, it *does* invoke undefined behaviour, not implementation
    defined behaviour.

    > I didn't say "only on the SUN". I used a similar
    > statement in a program to generate pdf files. It was ok when
    > compiled with gcc in DOS and Linux but not when compiled with gcc
    > on a SUN. Seems the DOS/Linux version of gcc first evaluates the
    > left side and then the right side whereas the opposite is true for
    > gcc on a SUN.
    santosh, Jul 20, 2007
    #1
    1. Advertising

  2. santosh

    Chris Dollin Guest

    santosh wrote:

    > On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <>
    > wrote in message <>:
    >
    >> santosh wrote:
    >>> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <>

    >>
    >>> > case 0x05: {la[--j] = la[j] / la[j+1]; break;}
    >>>
    >>> Why should this be an error? This exhibits undefined behaviour,
    >>> but that doesn't mean compilation should be stopped.


    >> It doesn't invoke undefined behaviour but a compiler dependent
    >> behaviour.

    >
    > AFAIK, it *does* invoke undefined behaviour, not implementation
    > defined behaviour.


    You're both right.

    The behaviour is undefined by the C standard. "Undefined" means "anything
    can happen, and no-one need document /what/ happens; it's all OK as far as
    I [1] am concerned".

    The /actual/ behaviour will depend on the implementation (not just on the
    compiler). It isn't "implementation-dependent" by the Standard's terms,
    because that phrase includes a requirement that the behaviour be
    /documented/.

    The C Standard is also silent on whether there are "warnings" or "errors".
    There are things that require a disgnostic, but whether those will "abort"
    compilation (ie not generate an object file, if the implementation uses
    such things) or let it continue are outside the domain of the Standard.

    (fx:OT) GCC, of course, lets you convert warnings into errors. If one
    writes one's code so that as a matter of course it generates no
    warnings, then this allows you to spot iffy behaviour pretty smartly.
    If one's usual code provokes an ocean of warnings, then one learns
    to ignore warnings, and eventually, such a warning will come with
    teeth, poison, fiery breath, and an unfortunate letter from your boss.

    [1] I, the Standard.

    --
    Hewlett-Packard Limited registered no:
    registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
    Chris Dollin, Jul 20, 2007
    #2
    1. Advertising

  3. santosh said:

    > On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <>
    > wrote in message <>:
    >
    >> santosh wrote:
    >>> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <>

    >>
    >>> > There is only one real warning:
    >>> >

    [UB code goes here]
    >>>
    >>> Why should this be an error? This exhibits undefined behaviour,
    >>> but that doesn't mean compilation should be stopped.

    >>
    >> I don't care whether the compilation stops or not. But if the
    >> behaviour of the generated code not only depends on the C source
    >> code but also on the concrete implementation of the compiler, then
    >> the source code is incorrect. And therefore an error and not a
    >> warning has to be generated.


    <good Santosh paragraph snipped>

    > Conforming compilers are required to stop compilation only if an
    > active #error preprocessor directive is encountered. Anything else
    > *can* be successfully compiled, though a diagnostic is mandatory for
    > each constraint violation.


    Well, he's said he doesn't care about that, but he appears to be drawing
    a distinction between errors and warnings which you don't seem to have
    noticed, and therefore you haven't addressed it.

    Such a distinction does not exist in C. All such messages are diagnostic
    messages. The C Standard makes little or no mention of "error messages"
    or "warning messages". And diagnostic messages are *required* only in
    the event of a #error (in which case compilation stops), a syntax
    error, or a constraint violation. Should any of these three occur at
    least once in the translation unit, the implementation is required to
    produce at least one diagnostic message. It is free to produce such
    messages at other times as well if it likes, and it is even free to pin
    labels such as "warning" or "error" onto its messages. The text of the
    messages is completely within its control.

    If the OP were a comp.lang.c reader, he might have learned something
    useful today. Oh well.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jul 20, 2007
    #3
  4. Chris Dollin said:

    > santosh wrote:
    >
    >> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <>
    >> wrote in message <>:
    >>
    >>> santosh wrote:
    >>>> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <>
    >>>
    >>>> > case 0x05: {la[--j] = la[j] / la[j+1]; break;}
    >>>>
    >>>> Why should this be an error? This exhibits undefined behaviour,
    >>>> but that doesn't mean compilation should be stopped.

    >
    >>> It doesn't invoke undefined behaviour but a compiler dependent
    >>> behaviour.

    >>
    >> AFAIK, it *does* invoke undefined behaviour, not implementation
    >> defined behaviour.

    >
    > You're both right.


    Well, actually Santosh is right, Chris, and you're wrong. :) Or at
    least partly wrong.

    > The behaviour is undefined by the C standard. "Undefined" means
    > "anything can happen, and no-one need document /what/ happens; it's
    > all OK as far as I [1] am concerned".
    >
    > The /actual/ behaviour will depend on the implementation (not just on
    > the compiler).


    As far as the Standard is concerned, it can also depend on other factors
    outside the implementation's purview. Once the behaviour is undefined,
    *all* bets are off, including the bet that the implementation can
    control what is going on.

    > It isn't "implementation-dependent" by the Standard's
    > terms, because that phrase includes a requirement that the behaviour
    > be /documented/.


    Not so (and this is where you're wrong). The term
    "implementation-dependent" does not appear within the text of the
    Standard, and implementation-dependent behaviour need not be
    documented. It is implementation-*defined* behaviour that must be
    documented.

    > The C Standard is also silent on whether there are "warnings" or
    > "errors". There are things that require a disgnostic,


    <resistance value="0.01 milliOhm">
    Presumably such things are unknowable.
    </resistance>

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jul 20, 2007
    #4
  5. santosh

    Chris Dollin Guest

    Richard Heathfield wrote:

    > Chris Dollin said:


    (fx:snip)

    > Well, actually Santosh is right, Chris, and you're wrong. :) Or at
    > least partly wrong.


    Argh! My reputation lies in tatters!

    (fx:pause)

    /Tatters/. Not /taters/. Preciouss.

    >> The behaviour is undefined by the C standard. "Undefined" means
    >> "anything can happen, and no-one need document /what/ happens; it's
    >> all OK as far as I [1] am concerned".
    >>
    >> The /actual/ behaviour will depend on the implementation (not just on
    >> the compiler).

    >
    > As far as the Standard is concerned, it can also depend on other factors
    > outside the implementation's purview. Once the behaviour is undefined,
    > *all* bets are off, including the bet that the implementation can
    > control what is going on.


    I could weasel about how the implementation has control but chooses
    to yeild it, or is more than just the machine plus its code, but
    just consider it done; yes, it's even worse than "the implementation
    decides".

    What happens may vary between implementations. It may vary within an
    implementation. It may vary: verily, it may be very vexatiously variable.

    >> It isn't "implementation-dependent" by the Standard's
    >> terms, because that phrase includes a requirement that the behaviour
    >> be /documented/.

    >
    > Not so (and this is where you're wrong). The term
    > "implementation-dependent" does not appear within the text of the
    > Standard, and implementation-dependent behaviour need not be
    > documented. It is implementation-*defined* behaviour that must be
    > documented.


    Drat. Good catch. TGIF.

    >> The C Standard is also silent on whether there are "warnings" or
    >> "errors". There are things that require a disgnostic,

    >
    > <resistance value="0.01 milliOhm">
    > Presumably such things are unknowable.
    > </resistance>


    Ah, a man after my own .

    --
    Chris "running hard" Dollin

    Hewlett-Packard Limited registered no:
    registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
    Chris Dollin, Jul 20, 2007
    #5
  6. santosh

    T.M. Sommers Guest

    santosh wrote:
    > On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <>
    > wrote in message <>:
    >
    >>It doesn't invoke undefined behaviour but a compiler dependent
    >>behaviour.

    >
    > AFAIK, it *does* invoke undefined behaviour, not implementation
    > defined behaviour.


    Undefined behavior *is* "compiler dependent behaviour [sic]", in
    the sense that the compiler can do whatever it wants to do when
    it encounters u.b.

    --
    Thomas M. Sommers -- -- AB2SB
    T.M. Sommers, Jul 20, 2007
    #6
  7. "T.M. Sommers" <> writes:
    > santosh wrote:
    >> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <>
    >> wrote in message <>:
    >>>It doesn't invoke undefined behaviour but a compiler dependent
    >>>behaviour.

    >> AFAIK, it *does* invoke undefined behaviour, not implementation
    >> defined behaviour.

    >
    > Undefined behavior *is* "compiler dependent behaviour [sic]", in the
    > sense that the compiler can do whatever it wants to do when it
    > encounters u.b.


    It *can* do whatever it wants, but it's not required to.

    --
    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, Jul 20, 2007
    #7
  8. santosh

    Flash Gordon Guest

    Keith Thompson wrote, On 20/07/07 18:35:
    > "T.M. Sommers" <> writes:
    >> santosh wrote:
    >>> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <>
    >>> wrote in message <>:
    >>>> It doesn't invoke undefined behaviour but a compiler dependent
    >>>> behaviour.
    >>> AFAIK, it *does* invoke undefined behaviour, not implementation
    >>> defined behaviour.

    >> Undefined behavior *is* "compiler dependent behaviour [sic]", in the
    >> sense that the compiler can do whatever it wants to do when it
    >> encounters u.b.

    >
    > It *can* do whatever it wants, but it's not required to.


    A number of processors, including the latest from Intel, include opcode
    sequences which are undefined, if the compiler emits such a sequence
    then Intel won't guarantee the behaviour either, and in the real word it
    could depend on variances in the manufacture of the processor, the
    temperature of the processor, the exact supply voltage etc.
    --
    Flash Gordon
    Flash Gordon, Jul 20, 2007
    #8
  9. "Richard Heathfield" <> wrote in message
    news:...
    > As far as the Standard is concerned, it can also depend on other factors
    > outside the implementation's purview. Once the behaviour is undefined,
    > *all* bets are off, including the bet that the implementation can
    > control what is going on.
    >

    Which it frequently does. "segmentation fault" is not a malfunction, it is
    the system giving correct output given the limitations of an incorrect
    executable.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Jul 20, 2007
    #9
    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. Song
    Replies:
    0
    Views:
    568
  2. F. GEIGER
    Replies:
    9
    Views:
    1,217
    F. GEIGER
    May 3, 2004
  3. C GIllespie

    wxpython demo under linux

    C GIllespie, May 12, 2004, in forum: Python
    Replies:
    2
    Views:
    480
    Sion Arrowsmith
    May 12, 2004
  4. Andy Leszczynski

    wxPython demo /Process does not open new demo

    Andy Leszczynski, Feb 18, 2005, in forum: Python
    Replies:
    1
    Views:
    637
    Andy Leszczynski
    Feb 18, 2005
  5. Herbert Kleebauer

    Re: Linux X demo

    Herbert Kleebauer, Jul 21, 2007, in forum: C Programming
    Replies:
    12
    Views:
    521
    Richard Bos
    Jul 23, 2007
Loading...

Share This Page