Richard Heathfield wrote, On 21/11/08 18:10:
Nick Keighley said:
<snip>
>Richard Heathfield seems to believe incorrect results are better
than a crash on the grounds that you can detect incorrect results.
Well I'm not so sure. If it were that easy to calculate the
correct results why are you bothering to run the program at
all?
If I as the programmer can't decide, for a given set of inputs, what the
outputs should be, I am in no position to write the program in the first
place.
There are very useful programs for which a programmer is not going to be
able to decide on what the correct output is prior to running the
program. A simple example is a program for calculating prime numbers
larger than a specified value. If the specified value is the largest
currently known prime number (which is a useful starting point) then the
programmer obviously does not know what the correct output is.
>I don't want my program to produce incorrect results
and then merrily run on.
I don't want my program to produce incorrect results. But if it's going to
do that, I'd rather be able to find out why. And that task is generally a
lot easier if I know what the incorrect results *are*. If the program just
crashes, I am deprived of useful debugging information.
In my experience if the crash is at time t and the incorrect results (if
a crash is prevented) can be spotted at time t+delta (for some positive
delta) then you can can more information from the crash since it is
nearer the actual bug.
What's more, I am
left wondering what damage the program may have done in the way of
filesystem corruption, dropped packets, etc during its route from
undefined behaviour to crash.
<snip>
There is the same problem if you get incorrect results. How do you know
it has not, for example, updated a million records in your database with
garbage values before the visibly incorrect result is seen?
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/ 5  1751 
Flash Gordon wrote:
Richard Heathfield wrote, On 21/11/08 18:10:
Nick Keighley said:
<snip>
Richard Heathfield seems to believe incorrect results are better
than a crash on the grounds that you can detect incorrect results.
Well I'm not so sure. If it were that easy to calculate the
correct results why are you bothering to run the program at
all?
If I as the programmer can't decide, for a given set of inputs, what the
outputs should be, I am in no position to write the program in the first
place.
There are very useful programs for which a programmer is not going to be
able to decide on what the correct output is prior to running the
program. A simple example is a program for calculating prime numbers
larger than a specified value. If the specified value is the largest
currently known prime number (which is a useful starting point) then the
programmer obviously does not know what the correct output is.
This is true only in an absurd sense. In a practical sense, the answer
must satisfy the constraints. In some cases it will be hard to verify that
it does, but the constraints are still known. Heathfield was commenting on
the case where the programmer doesn't even know the constraints, thus
doesn't even know what to write.
But you knew that, right?
blargg wrote, On 21/11/08 20:08:
Flash Gordon wrote:
>Richard Heathfield wrote, On 21/11/08 18:10:
>>Nick Keighley said:
<snip>
Richard Heathfield seems to believe incorrect results are better
than a crash on the grounds that you can detect incorrect results.
Well I'm not so sure. If it were that easy to calculate the
correct results why are you bothering to run the program at
all?
If I as the programmer can't decide, for a given set of inputs, what the
outputs should be, I am in no position to write the program in the first
place.
There are very useful programs for which a programmer is not going to be
able to decide on what the correct output is prior to running the
program. A simple example is a program for calculating prime numbers
larger than a specified value. If the specified value is the largest
currently known prime number (which is a useful starting point) then the
programmer obviously does not know what the correct output is.
This is true only in an absurd sense.
No, I don't think so.
In a practical sense, the answer
must satisfy the constraints.
Yes.
In some cases it will be hard to verify that
it does, but the constraints are still known.
The case I mentioned verifying the constraints are met is easy. In other
situations verifying the constraints are met for real data can be as
complex as the original problem. In other situations verifying the final
result is (comparatively) easy, but verifying the intermediate steps is
extremely difficult.
Heathfield was commenting on
the case where the programmer doesn't even know the constraints, thus
doesn't even know what to write.
But you knew that, right?
That was not what he said and, in my opinion, it is a very different
statement.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Flash Gordon said:
Richard Heathfield wrote, On 21/11/08 18:10:
>Nick Keighley said:
<snip>
>>Richard Heathfield seems to believe incorrect results are better
than a crash on the grounds that you can detect incorrect results.
Well I'm not so sure. If it were that easy to calculate the
correct results why are you bothering to run the program at
all?
If I as the programmer can't decide, for a given set of inputs, what the
outputs should be, I am in no position to write the program in the first
place.
There are very useful programs for which a programmer is not going to be
able to decide on what the correct output is prior to running the
program. A simple example is a program for calculating prime numbers
larger than a specified value. If the specified value is the largest
currently known prime number (which is a useful starting point) then the
programmer obviously does not know what the correct output is.
Sure. So you test it on known prime numbers. BIG known prime numbers. If it
can find a few million big known primes, I would trust it to produce a
hitherto unknown prime candidate for checking with known-good
primality-testing programs using different algorithms. (If you have those
other programs, why bother writing this one? Well, maybe it's a speed
thing - maybe it can discard pseudoprimes much quicker than other
programs, say.)
>>I don't want my program to produce incorrect results
and then merrily run on.
I don't want my program to produce incorrect results. But if it's going
to do that, I'd rather be able to find out why. And that task is
generally a lot easier if I know what the incorrect results *are*. If
the program just crashes, I am deprived of useful debugging information.
In my experience if the crash is at time t and the incorrect results (if
a crash is prevented) can be spotted at time t+delta (for some positive
delta) then you can can more information from the crash since it is
nearer the actual bug.
It's just a symptom, not a cause. And it's merely a fact. "We got this far,
and it crashed." But you don't actually know why. Yes, backtraces are very
useful. I'm not saying you *can't* debug a segfault. And it's not even
*that* difficult to do. But I'd rather debug incorrect results any day.
And I certainly wouldn't want my code to crash in production. I wish I
could claim that my code never does crash in production. Of course,
sometimes it does happen, but it's a circumstance that I would very much
prefer to avoid.
>
>What's more, I am
left wondering what damage the program may have done in the way of
filesystem corruption, dropped packets, etc during its route from
undefined behaviour to crash.
<snip>
There is the same problem if you get incorrect results.
No, sir, there isn't - if the behaviour of your program is *well-defined*,
you know the limits of what it can do. If the behaviour of your program is
undefined, all bets are off. And a crash is basically one aspect of
undefined behaviour.
How do you know
it has not, for example, updated a million records in your database with
garbage values before the visibly incorrect result is seen?
If it's a well-defined program, I know it didn't do that because it's a
graphics filter, not a database program. But if the behaviour were
undefined, I couldn't be sure.
--
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 wrote, On 21/11/08 22:43:
Flash Gordon said:
>Richard Heathfield wrote, On 21/11/08 18:10:
>>Nick Keighley said:
<snip>
Richard Heathfield seems to believe incorrect results are better
than a crash on the grounds that you can detect incorrect results.
Well I'm not so sure. If it were that easy to calculate the
correct results why are you bothering to run the program at
all?
If I as the programmer can't decide, for a given set of inputs, what the
outputs should be, I am in no position to write the program in the first
place.
There are very useful programs for which a programmer is not going to be
able to decide on what the correct output is prior to running the
program. A simple example is a program for calculating prime numbers
larger than a specified value. If the specified value is the largest
currently known prime number (which is a useful starting point) then the
programmer obviously does not know what the correct output is.
Sure. So you test it on known prime numbers. BIG known prime numbers. If it
can find a few million big known primes, I would trust it to produce a
hitherto unknown prime candidate for checking with known-good
primality-testing programs using different algorithms. (If you have those
other programs, why bother writing this one? Well, maybe it's a speed
thing - maybe it can discard pseudoprimes much quicker than other
programs, say.)
That is still not knowing the answer in advance. If you have an
additional requirement that it be the next highest prime number then
even proving that the result is a prime won't prove that it is the
correct output.
>>>I don't want my program to produce incorrect results
and then merrily run on.
I don't want my program to produce incorrect results. But if it's going
to do that, I'd rather be able to find out why. And that task is
generally a lot easier if I know what the incorrect results *are*. If
the program just crashes, I am deprived of useful debugging information.
In my experience if the crash is at time t and the incorrect results (if
a crash is prevented) can be spotted at time t+delta (for some positive
delta) then you can can more information from the crash since it is
nearer the actual bug.
It's just a symptom, not a cause.
So are the incorrect results.
And it's merely a fact. "We got this far,
and it crashed." But you don't actually know why.
The same applies to incorrect results.
Yes, backtraces are very
useful. I'm not saying you *can't* debug a segfault. And it's not even
*that* difficult to do. But I'd rather debug incorrect results any day.
I would rather debug starting from as close to where the error is as
possible.
And I certainly wouldn't want my code to crash in production.
Same here. As a result on a legacy project I have slowly added in lots
of traps for "impossible" conditions.
I wish I
could claim that my code never does crash in production. Of course,
sometimes it does happen, but it's a circumstance that I would very much
prefer to avoid.
I try to avoid it as well. I'm also not arguing that crashes are a good
thing, although repeatable crashes can be easy to debug.
>>What's more, I am
left wondering what damage the program may have done in the way of
filesystem corruption, dropped packets, etc during its route from
undefined behaviour to crash.
<snip>
There is the same problem if you get incorrect results.
No, sir, there isn't - if the behaviour of your program is *well-defined*,
you know the limits of what it can do. If the behaviour of your program is
undefined, all bets are off. And a crash is basically one aspect of
undefined behaviour.
With a lot of SW the limits within well defined behaviour can include
completely trashing your data.
>How do you know
it has not, for example, updated a million records in your database with
garbage values before the visibly incorrect result is seen?
If it's a well-defined program, I know it didn't do that because it's a
graphics filter, not a database program. But if the behaviour were
undefined, I couldn't be sure.
You introduced networking as a possibility, I introduced databases.
I'm not arguing in favour of undefined behaviour, just that a crash
closer to the point of error can be faster to debug than a detected
incorrect further away. Personally I would generally try and trap
conditions which would otherwise crash the program and handle them, on
one application I've been working on that handling can mean aborting the
program with a suitable error message.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Flash Gordon said:
<snip>
even proving that the result is a prime won't prove that it is the
correct output.
Okay, fair point. So how are you going to test it? You *were* going to test
it, right? And how would crashing solve your problem here?
<snip>
>>In my experience if the crash is at time t and the incorrect results
(if a crash is prevented) can be spotted at time t+delta (for some
positive delta) then you can can more information from the crash since
it is nearer the actual bug.
It's just a symptom, not a cause.
So are the incorrect results.
Yes.
>And it's merely a fact. "We got this far,
and it crashed." But you don't actually know why.
The same applies to incorrect results.
Incorrect results typically give you more information about what went wrong
than no results whatsoever. If your output is:
"MANCHESTER UNITED 0, LEEDS UNITE"
you've already got a pretty good idea of what went wrong, right there. Or
if it's "MANCHESTER UNITED 0, LEEDS UNITED -2147483648, that's a pretty
big clue, too. But if it's, then you have to start guessing.
>
>Yes, backtraces are very
useful. I'm not saying you *can't* debug a segfault. And it's not even
*that* difficult to do. But I'd rather debug incorrect results any day.
I would rather debug starting from as close to where the error is as
possible.
I would rather debug starting from as much relevant information about the
error as possible - including, but not limited to, its ostensible
locality.
>And I certainly wouldn't want my code to crash in production.
Same here.
Then what are we arguing about? :-)
As a result on a legacy project I have slowly added in lots
of traps for "impossible" conditions.
Quotes noted with wry smile. Been there, done that, got the impossible
tee-shirt.
>I wish I
could claim that my code never does crash in production. Of course,
sometimes it does happen, but it's a circumstance that I would very much
prefer to avoid.
I try to avoid it as well. I'm also not arguing that crashes are a good
thing, although repeatable crashes can be easy to debug.
Yes, "repeatable" being the important word here. I've found that keeping
the behaviour well-defined is a great aid to repeatability, and
well-defined behaviour means no crash - QED! :-)
>>>What's more, I am
left wondering what damage the program may have done in the way of
filesystem corruption, dropped packets, etc during its route from
undefined behaviour to crash.
<snip>
There is the same problem if you get incorrect results.
No, sir, there isn't - if the behaviour of your program is
*well-defined*, you know the limits of what it can do. If the behaviour
of your program is undefined, all bets are off. And a crash is basically
one aspect of undefined behaviour.
With a lot of SW the limits within well defined behaviour can include
completely trashing your data.
Yes, but only the relevant data! The data that you know to look at, because
it's within the domain of the program's activity. With undefined
behaviour, you have to check Keith Thompson's hard disk, in case your
program running on your machine messed it up. Okay, so that's a caricature
- but the underlying point is genuine.
>>How do you know
it has not, for example, updated a million records in your database
with garbage values before the visibly incorrect result is seen?
If it's a well-defined program, I know it didn't do that because it's a
graphics filter, not a database program. But if the behaviour were
undefined, I couldn't be sure.
You introduced networking as a possibility, I introduced databases.
Sure, but my point is that IF the behaviour is well-defined, you only have
to look in the relevant places. If the behaviour is undefined, you have to
look in what would otherwise be irrelevant places - or trust that the
undefined behaviour *didn't* screw your system in some arbitrarily subtle
way.
I'm not arguing in favour of undefined behaviour, just that a crash
closer to the point of error can be faster to debug than a detected
incorrect further away. Personally I would generally try and trap
conditions which would otherwise crash the program and handle them,
Right. So would I.
on
one application I've been working on that handling can mean aborting the
program with a suitable error message.
I don't consider dev-time assertions to be crashes.
--
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Nomen Nescio |
last post by:
A new learner's question
Flash Gordon wrote:
To the OP, please be aware that Flash Gordon has a history of either
deliberately misleading and "miss-informing" posters to this
newsgroup or...
|
by: Nomen Nescio |
last post by:
what is the type for this call?
Neo said:
Neo, buddy, I've decided to give you a little summary for reference
so that you don't have to sift through excess verbiage, cryptic
meanderings,...
|
by: Nomen Nescio |
last post by:
No format string passed to variable argument list function
Adam said:
Then Adam laters says:
Then Adam later says:
|
by: Chris Dollin |
last post by:
Joachim Schmitz wrote:
I think that remark is an ill-considered and unhelpful generalisation.
--
"We dance, and the worlds melt away." - Curved Air, /Metamorphosis/
...
|
by: Borked Pseudo Mailed |
last post by:
float and integers
c.lang.myself@gmail.com said
I will be making assumptions here about your system that will
infuriate the pedants, but I don't care. Given your X-HTTP-UserAgent
string, it...
| | |
by: George Orwell |
last post by:
its urgent.pls help me.
mona said:
mona said:
Hey again, mona.
Please check the thread "(part 21) Han from China answers
your C questions", in which I gave you a program with
|
by: George Orwell |
last post by:
fread breaks file descriptors opened in "w" mode.
...
Yes, once you break out of ANSI/ISO C, all things are possible.
You have posted an on-topic question to comp.lang.c. See version 2.0 of...
|
by: Borked Pseudo Mailed |
last post by:
Error handling in C
Nick Keighley said:
...
...
To the OP, please be aware that Nick Keighley is a known troll
and is deliberately providing you with unsound advice. You asked
for error...
|
by: Nomen Nescio |
last post by:
What is this?
Eric said:
That looks like either someone's poor coding or someone's poor
pasting for an implementation of offsetof() from stddef.h. The
(char *) leads me to think that there's...
|
by: George Orwell |
last post by:
File Seeking / Overwriting bytes
Martien Verbruggen said:
And this is, of course, also not right. fseek() does support
SEEK_END on text streams.
If you want to know why, please start a...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
| | |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| | |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
