C dangerous?

D

Dan Pop

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.

You're changing your initial story:

Yes. The machine restarted spontaneously, and failed to detect the hard
disks on the restart. (A cold boot fixed it, thank heaven.)

How could it report a disk failure about a disk it failed to detect?!?

If you change your story arbitrarily, it becomes impossible to have a
meaningful discussion. Tomorrow you may even claim that you saw some
smoke getting out of the disk drive... Next week, you may also add some
strange noises coming from the same place and so on.
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]>

And when asked to elaborate, you posted the text I have quoted above.
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.

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.

However, there is a whole world of difference between a real disk failure
and the BIOS reporting a disk failure. FYI: real disk failures don't get
fixed by cold boots.

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.

I'm working in a medium sized computer centre and I've seen plenty of
weird things related to disks. Like disks that pass all the vendor's
tests and work in most computers, but aren't even detected by a certain
RAID controller (although the same RAID controller detected and happily
used them two weeks before). But when the thing starts happening, no
amount of cold booting changes anything. And, for obvious reasons, I'm
reluctant to call it a disk failure.

Dan
 
B

Bill Cunningham

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.

Bill
 
D

Dan Pop

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

Brilliant! Now, Richard will have to use his mind reading capabilities
in order to be able to figure out what is your problem...

You must be either extremely stupid or extremely intelligent (in order to
simulate extreme stupidity so well).

Dan
 
D

Default User

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.


Oh, hey, if you're going back in time, could you email a message to me
back then? Just some stock advice, no biggie.



Brian Rodenborn
 
M

Michael Wojcik

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.

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

Mark McIntyre

Not quite sure what you're not saying.

Alright I'll bite. You're being something of a hypocrite, which I've
noticed its your style when engaging in flame wars. You often assert
something and insist you don't need to prove it, then pour scorn on your
opponent when he asserts something and similarly decides not to prove it
for you.

FWIW I agree, you don't need to prove this. But please remember to put this
boot on the other foot when responding to other people's posts, and accord
them the same courtesy rather than gratuitously attributing their decision
to malice or fear.
Chapter and verse, please,

I have yet to see any reason why I /should/ provide C&V. If you choose not
to believe me, etc.
from ISO/IEC 9899:1990 (which was the standard to
which the compiler that I tested the program on claimed to conform).

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

Mark McIntyre

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.

Sure, disk /access/ failure, scribbled on data, unable to boot from the
device etc. But to actually damage the disk electronics so that the BIOS
reports the disk as being nonexistent or defective? Thats pretty unlikely
IMHO.
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.

Not really.
 
R

Richard Heathfield

Mark said:
Alright I'll bite. You're being something of a hypocrite,

Am I? I didn't think I was, but I'm prepared to take your word for it on
this occasion.
 
R

Richard Heathfield

Mark said:
And now you're just being childish.
Both of you.

Thanks. :)

Seriously, as this thread has drifted away from the C programming language,
it has got more and more tiresome. Dan has the floor, and he can keep it.
 
N

Nils Petter Vaskinn

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?

By the way: Dan, meet Occam, you two may have something to talk about.
Dunno about computer science, but in other sciences, people who draw
conclusions from single experiments are the laughingstocks of the
corresponding communities.

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)

So everyone was wrong and we can all go home, the problem was "Temporary
failure to successfully boot from the drive (reported by the bios as
disk failure though it may not have been) due to some unknown cause"
 
M

Mark F. Haigh

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.

I'm drawing a blank. Which is it? I may have to go rent it.

Mark S.
 
D

Dan Pop

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.

You have still to prove the existence of PC disks that are not immune to
this kind of abuse.

Dan
 
D

Dan Pop

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?

It was presented by Richard as a program likely to cause harm on certain
Windows versions, not by me.

I was merely explained in what conditions Richard's correlation would have
any credibility.
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)

And this is definitely not me. My phrasing was crystal clear and only
an idiot could imply from it what you did.

Dan
 
P

Programmer Dude

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.

The really silly part is they're both right. It wasn't--in the
strict and literal sense--a disk failure, but the "thing" that
happened to Richard is *commonly* and *frequently* referred to
as a "disk failure". Short hand for 'disk failed to operate
correctly this time'.
 

Ask a Question

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.

Ask a Question

Similar Threads

[C#] Extend main interface on child level 0
C language now truly universal 0
Dennis Ritchie -- An Appreciation 269
I'm tempted to quit out of frustration 1
C Bibliography 17
TF-IDF 1
Limbajul C 5
C Is Not Assembly 6

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top