Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Linux X demo

Reply
Thread Tools

Re: Linux X demo

 
 
santosh
Guest
Posts: n/a
 
      07-20-2007
On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <(E-Mail Removed)>
wrote in message <(E-Mail Removed)>:

> santosh wrote:
>> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <(E-Mail Removed)>

>
>> > 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.



 
Reply With Quote
 
 
 
 
Chris Dollin
Guest
Posts: n/a
 
      07-20-2007
santosh wrote:

> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <(E-Mail Removed)>
> wrote in message <(E-Mail Removed)>:
>
>> santosh wrote:
>>> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <(E-Mail Removed)>

>>
>>> > 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

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      07-20-2007
santosh said:

> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <(E-Mail Removed)>
> wrote in message <(E-Mail Removed)>:
>
>> santosh wrote:
>>> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <(E-Mail Removed)>

>>
>>> > 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
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      07-20-2007
Chris Dollin said:

> santosh wrote:
>
>> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <(E-Mail Removed)>
>> wrote in message <(E-Mail Removed)>:
>>
>>> santosh wrote:
>>>> On Friday 20 Jul 2007 2:36 am, Herbert Kleebauer <(E-Mail Removed)>
>>>
>>>> > 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
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-20-2007
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!

(fxause)

/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

 
Reply With Quote
 
T.M. Sommers
Guest
Posts: n/a
 
      07-20-2007
santosh wrote:
> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <(E-Mail Removed)>
> wrote in message <(E-Mail Removed)>:
>
>>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 -- http://www.velocityreviews.com/forums/(E-Mail Removed) -- AB2SB

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      07-20-2007
"T.M. Sommers" <(E-Mail Removed)> writes:
> santosh wrote:
>> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <(E-Mail Removed)>
>> wrote in message <(E-Mail Removed)>:
>>>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) (E-Mail Removed) <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"
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      07-20-2007
Keith Thompson wrote, On 20/07/07 18:35:
> "T.M. Sommers" <(E-Mail Removed)> writes:
>> santosh wrote:
>>> On Friday 20 Jul 2007 5:41 am, Herbert Kleebauer <(E-Mail Removed)>
>>> wrote in message <(E-Mail Removed)>:
>>>> 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
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      07-20-2007

"Richard Heathfield" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Linux X demo Herbert Kleebauer C Programming 12 07-23-2007 10:23 AM
wxPython demo /Process does not open new demo Andy Leszczynski Python 1 02-18-2005 06:03 PM
wxpython demo under linux C GIllespie Python 2 05-12-2004 02:34 PM
PyOpenGL demo in wxPython demo crashes F. GEIGER Python 9 05-03-2004 04:43 PM
UT2004 Demo for Linux, Win and Mac is out... steve NZ Computing 9 02-18-2004 06:16 AM



Advertisments