P
pete
Bill said:How can C damage your computer?
If the computer that you programmed,
catches fire at a trade show, you will be razzed.
Bill said:How can C damage your computer?
In said:Because the computer's BIOS display screen thing told me on startup that
there was a disk failure. I forget the exact wording.
I didn't say Windows failed to detect the disk. I said the program I quoted
caused a disk failure on my Windows 2000 box.
See Message ID <[email protected]>
I don't, for sure. But when I chuck a ball at a pane of glass, and the ball
hits the glass, and the glass breaks, it's not unreasonable to deduce that
the ball (and my throwing it) had something to do with the glass breaking.
Similar logic applies here.
In said:Dan Pop wrote:
<sigh> If you say so. </sigh>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^In said:Richard,
I'm not quite sure what's going on with the this person said this, then
this one this, etc. Am I not cutting right or is it someone else? I cut
everything from this message. ^^^^^
Richard said:Not quite sure what you're not saying. What does Dan want me to do? Go back
in time, get a JPEG of the BIOS screen, and paste it on my site so that all
the world can see for themselves that the disk failed? Yeah, right, I'll
get straight onto it.
Dan said:
FWIW while I accept completely that you saw a disk failure immediately
after the restart, I don't believe that this specific bug can actually
*cause* a disk failure.
Not quite sure what you're not saying.
Chapter and verse, please,
from ISO/IEC 9899:1990 (which was the standard to
which the compiler that I tested the program on claimed to conform).
Why not? The bug in question causes code running in privileged mode
(ring 0) to fail in unpredictable ways. It's certainly possible that
in general such a fault can, say, write invalid data to memory-mapped
controler ports.
The two Windows cmd.exe bugs caused abrupt and total OS failure. That
was well-documented by many people who experimented with them,
including me. And when the OS goes belly-up, all bets are off.
Mark said:Alright I'll bite. You're being something of a hypocrite,
Mark said:And now you're just being childish.
Both of you.
Nope, not necessarily, in the absence of enough data. You cannot
exclude a coincidence. If that happended 10 times out of 10, then you
had some solid ground to claim that, after running that program, your
BIOS reports a disk failure.
[snip]
So, even with your revised story, there is still no disk failure in
sight. And we still don't know whether the BIOS failure to initialise
the disk was triggered by running the program in question, due to lack
of enough experimental data.
Dunno about computer science, but in other sciences, people who draw
conclusions from single experiments are the laughingstocks of the
corresponding communities.
Ben said:My favorite is a movie where someone spills coffee on the
keyboard, causing the entire building and everything in it to
turn invisible.
Mark said:I'm drawing a blank. Which is it? I may have to go rent it.
Mark S.
Why not? The bug in question causes code running in privileged mode
(ring 0) to fail in unpredictable ways. It's certainly possible that
in general such a fault can, say, write invalid data to memory-mapped
controler ports.
In said:Nope, not necessarily, in the absence of enough data. You cannot
exclude a coincidence. If that happended 10 times out of 10, then you
had some solid ground to claim that, after running that program, your
BIOS reports a disk failure.
[snip]
So, even with your revised story, there is still no disk failure in
sight. And we still don't know whether the BIOS failure to initialise
the disk was triggered by running the program in question, due to lack
of enough experimental data.
The program in question that made an OS bug cause undefined behaviour
resulting in a crash? Do you expect the exact conditions during the crash
to be reproducible?
And those that draw conclusions from insufficient information about single
experiments?
???
You were implying that the likely problem was filesystem corruption not
disk failure. (In <[email protected]> ). (if that wasn't what
you were implying then at least one of us needs to imrove his grasp of the
english language, and at least one of needs to try to be more clear)
Mark said:I fail utterly to see what relevance the C ISO Standard has to a
silly argument between you and Dan about whether a bug in some
piece of code did (or did not) cause some unexpected behaviour
in your hardware.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.