C dangerous?

[Dan Pop]

I cannot imagine how the filesystem could be broken in such a way that a
cold reboot will find it while a hot reboot won't, that's why I don't buy
the filesystem corruption idea. Unfortunately RH didn't state if the bios
saw the drive wile the os didn't.

Are you denser than usual in this thread or what? The filesystem
corruption scenario I have mentioned have ABSOLUTELY nothing in common
with RH's scenario, period.

The type of boot is COMPLETELY irelevant to my scenario: the filesystem
corruption will be there no matter how the system is booted after
being crashed by RH's program. The *only* thing that matters, to my
scenario, is the filesystem state at the point the system crashed.
If some filesystem data has been changed but the changes have not been
yet completely written to the disk, my scenario is likely to occur.
That's why Windows automatically performs a filesystem check after a
crash (regardless of the reason of the crash).

It is far more difficult to predict when RH's scenario can occur,
especially considering that it may not affect all high end Windows
versions in the same way (*another* bug, present only in RH's version
of Windows may be involved, too).

Dan

 

[Nils Petter Vaskinn]

Are you denser than usual in this thread or what?

Perhaps, but that doesn't mean anything before we have established what my
usual density is.

The filesystem
corruption scenario I have mentioned have ABSOLUTELY nothing in common
with RH's scenario, period.

The non-obvious effect of printing "\t\b\b\b\b\b" on the console of
certain high end Windows flavours is a system crash. If the system
crashes at the "right" moment, it can leave the filesystem in a bad
state, so that part of it can become unusable.

Of course, this doesn't qualify as disk failure, but this is a too fine
point for RH.

"but this is a too fine point for RH."

Excuse me if I parsed that as "I think RH had a currupted filesystem but
mistook it for a disk failure"

My argument was because I believed you meant that. If you didn't I
apologize, but then I believe maybe you should have phrased yourself
differently.

 

[Dan Pop]

Perhaps, but that doesn't mean anything before we have established what my
usual density is.



"but this is a too fine point for RH."

Excuse me if I parsed that as "I think RH had a currupted filesystem but
mistook it for a disk failure"

Nope, this is not what I meant. Otherwise I would have written it the
way you suggested.

As it happens, RH didn't have a disk failure at all. He had a failure
of the OS to recognise the disk and he hasn't enough data to establish
whether there was a correlation between the two events. For my laptop,
I do have enough data, yet I do not consider that it malfunctions after
booting Linux, even if Windows fails to hot boot after that, a behaviour
very similar to that observed by RH on his machine, after running the
program in question.

My argument was because I believed you meant that. If you didn't I
apologize, but then I believe maybe you should have phrased yourself
differently.

I had clearly explained that I was referring to the worst case scenario
and NOT to what RH actually observed. I had also clearly explained that
what RH observed was NOT a disk failure. You have no excuse for not
paying enough attention to what I wrote.

Dan

 

[Arthur J. O'Dwyer]

Em Wed, 18 Feb 2004 10:13:46 -0500, Kenneth Brody escreveu:

I think this program would only segfault on an *operating* system...

Well, naturally -- you wouldn't expect it to segfault on a *defunct*
system!

-Arthur

 

[Old Wolf]

Has anyone encountered a virus that actually harms the hardware of the

host computer? The virus-engineers usually quite clever when it comes
to malicious code.

(and I don't mean in an indirect way, e.g. annoying the user beyond
sanity so the user assualts the hardware from pure frustration)

On some computers, the CPU clock speed could be set in software.

 

[Mike Wahler]

I read an article in a book about Perl and Common Gateway Interface and it
mentioned C. It said that C could damage your computer.

Do you believe everything you read?

I don't know wether
it meant the standard or compiler issuses. I was a little upset. Well more
upset.

Why get upset about something which might or might not be true,
before actually finding out?

I sent Dennis Ritchie and email. I don't know if he'll respond if he
gets it. Sometimes he does sometimes not. How can C damage your computer?

C could cause damage to a computer for many of the same reasons
that a cell phone could cause damage to an automobile.

If you're really that paranoid, well then ...

Don't Drive!

-Mike

 

[James Dow Allen]

Of course I am!

"Do you want cream or sugar with your coffee?"
"Yes, please."
"Both?"
"No, just one."

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

You were running Microsoft software? You don't mean that
toy buggy system that's only used for play applications
(like Flight Simulater, FreeCell, voting machines, ATM machines,
and nuclear submarines)?

Shame on you!

My story's better. My hard disk was trashed by Microsoft
software on a machine where I ran *nothing* but Linux.

James

 

[Richard Heathfield]

As it happens, RH didn't have a disk failure at all.

Mr Pop is wrong. I do not expect him to understand this.

 

[Dan Pop]

On some computers, the CPU clock speed could be set in software.

Presumably, the same computers either don't allow setting the clock
above the maximum supported limit or the CPU has an overclocking
protection.

Dan

 

[Dan Pop]

Mr Pop is wrong. I do not expect him to understand this.

I understand your statement perfectly. Which doesn't make it right ;-)

Unlike RH, I have produced arguments to support my position. Which he
chose not to address, preferring to pontificate.

Dan

 

[Randy Howard]

| Unless it has access to the assembly instruction
| "HCF" - halt and catch fire

Has anyone encountered a virus that actually harms the hardware of the
host computer? The virus-engineers usually quite clever when it comes
to malicious code.

Of course this has been done before. Older PC monitors could be toasted
by setting the video scan rate to zero. This would turn the flyback
transformer into a relatively unportable toaster oven, briefly, until
the monitor burned out. A few early "screen savers" were turned into
malicious code by using this.

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


I understand your statement perfectly. Which doesn't make it right ;-)

Unlike RH, I have produced arguments to support my position.

The disk failure happened. Perhaps you should have presented your arguments
at the time. Then, perhaps, the disk wouldn't have /dared/ to fail. But you
weren't there and you didn't argue, so the disk failed despite your
arguments. When it comes to a choice between believing your logic and my
own eyes, I'll choose to believe my own eyes, every time.

If you think it was a filesystem corruption (and I admit I can't actually
remember whether you do or not), you are mistaken.

It was, in short, a disk failure.

Which he
chose not to address, preferring to pontificate.

So you say.

 

[Michael Wojcik]

Well, thanks for educating me here! I need to try this out the next time I
can lay hands on someone else's XP/2K box

Has someone cited [1], the c.l.c thread where, AFAIK, this was
originally documented?

Nor was this the only system-fatal bug in the WinNT/2K/XP cmd.exe
input handler. See [2].

Ah, Microsoft. Running the command shell in privileged mode. What
wacky hijinks will they get up to next?


1. http://groups.google.com/[email protected]

2. http://groups.google.com/[email protected]

 

[Bill Cunningham]

If you were not the patent idiot you are, you'd have realised that this is
a general software issue, having nothing to do with C.

I will continue to read your post Dan, even though it contains a flame and
not skip immediately to the next message because I know you know what
you're talking about.

So, IF it is possible to damage a computer via software, C is one of the
many languages that will allow you to do it. Any other low level language
or even high level language with an interface to the operating system
primitives will do the job. Or no language at all: ten years ago it was
perfectly possible to damage a monitor (fry the final transistor of the
horizontal deflection circuitry) with a text editor (under Linux) or the
mouse (under Windows). All you had to do was select a video mode the
monitor could not support.

It is also possible to abuse certain peripherals, e.g. hard and floppy
disks, by madly moving their heads for long periods of time. Depending
on their quality and age, this may physically damage them. But, again,
there is nothing C specific here.

The canonical example, 20 years ago, was an 8-bit Commodore home computer.
A single BASIC POKE instruction (the "right" value at the "right" address)
was enough to destroy something in the graphics hardware.

Dan

I had several Commodores. But the computer transistor I fried was a TSR
CoCo.

Bill

 

[Dan Pop]

The disk failure happened.

1. How do you know?

2. Why do you call Windows' failure to detect the disk as a disk failure?

3. How do you know that it was related to the execution of the code under
question? How many times have you repeated the experiment? For all
you know, Windows may have failed to detect the disk even after a
controlled reboot.

Perhaps you should have presented your arguments at the time.
Then, perhaps, the disk wouldn't have /dared/ to fail.

Please spare me your lame attempts at humour/sarcasm.

But you
weren't there and you didn't argue, so the disk failed despite your
arguments.

You have yet to prove that it failed.

When it comes to a choice between believing your logic and my
own eyes, I'll choose to believe my own eyes, every time.

And your eyes have shown you that Windows failed to detect the drive, not
that the drive failed. You foolishly jumped to a completely unsupported
conclusion.

If you think it was a filesystem corruption (and I admit I can't actually
remember whether you do or not), you are mistaken.

I never thought or claimed that it was filesystem corruption IN YOUR CASE.
I mentioned filesystem corruption as the worst thing that is likely
to happen from the execution on your program on a vulnerable Windows
version. I hope that even you can tell the difference between these two
statements.

It was, in short, a disk failure.

You're taking your beliefs for hard facts. If you're continuing along
these lines, you may well end up in a certain kind of asylum.

So you say.

Have you provided any kind of proof that Window's failure to detect the
disk was related to a disk failure?

As I said, in my case, my laptop won't hot boot Windows after Linux (but
will cold boot Windows any time). Does this mean that my laptop is
failing once it has booted Linux?

Dan

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


1. How do you know?

Because the computer's BIOS display screen thing told me on startup that
there was a disk failure. I forget the exact wording.

2. Why do you call Windows' failure to detect the disk as a disk failure?

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.

3. How do you know that it was related to the execution of the code under
question?

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.

How many times have you repeated the experiment?

0 times, for obvious reasons.

For all
you know, Windows may have failed to detect the disk even after a
controlled reboot.

What has that to do with anything? It was the machine that had the problem
with the disk. The OS had not, at this stage, even been booted. (How could
it, given that there was a disk failure on the boot disk?)

Please spare me your lame attempts at humour/sarcasm.

If you don't want to read what I write, don't read what I write.

You have yet to prove that it failed.

I have yet to see any reason why I /should/ prove it. If you choose not to
believe me, fine, don't believe me.

And your eyes have shown you that Windows failed to detect the drive, not
that the drive failed. You foolishly jumped to a completely unsupported
conclusion.

See above.

I never thought or claimed that it was filesystem corruption IN YOUR CASE.

Fine by me.

I mentioned filesystem corruption as the worst thing that is likely
to happen from the execution on your program on a vulnerable Windows
version. I hope that even you can tell the difference between these two
statements.

I can. Nevertheless, the disk failed.

You're taking your beliefs for hard facts.

You can believe that if you choose, but I think I can tell the difference
between a disk failure on startup and an OS failure to read a disk.

If you're continuing along
these lines, you may well end up in a certain kind of asylum.

I think you must have seriously misunderstood something I said. Again.

Have you provided any kind of proof that Window's failure to detect the
disk was related to a disk failure?

Windows hadn't booted, so how /could/ it fail to detect the disk?

As I said, in my case, my laptop won't hot boot Windows after Linux (but
will cold boot Windows any time). Does this mean that my laptop is
failing once it has booted Linux?

A more relevant question for this subthread would be: if Linux can't load
because the disk has failed, does /that/ mean the laptop is failing?

 

[Mark McIntyre]

I have yet to see any reason why I /should/ prove it. If you choose not to
believe me, fine, don't believe me.

I'm not going to say it, I'm not going to say it, I'm not.....

You can believe that if you choose, but I think I can tell the difference
between a disk failure on startup and an OS failure to read a disk.

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. It can however expose a hardware problem, as indeed
can any sudden reboot with the associated extra load on components.

Windows hadn't booted, so how /could/ it fail to detect the disk?

in fact, Dan must surely be right here when you think about it - since
Windows had not booted, it must necessarily have not detected the disk....

 

[Charles Sullivan]

In <[email protected]> "Peter Pichler"

...in his usual friendly style:

[...] ten years ago it was
perfectly possible to damage a monitor (fry the final transistor of the
horizontal deflection circuitry) with a text editor (under Linux) or
the mouse (under Windows). All you had to do was select a video mode
the monitor could not support.

Or simply by pulling the video cable with the monitor still on. That was
fun!

Not sure if it counts as a software method... ;-)

Dan

Quite a few years ago in the old "Mission Impossible" TV series, a member
of the good-guys team slipped a single 80-column IBM punch card into a
deck being run through the bad-guys' mainframe, with the result that the
entire mainframe went up in flames/explosions/smoke etc.

(Gotta be true or they wouldn't allow it on TV, right?)

 

[Ben Pfaff]

Quite a few years ago in the old "Mission Impossible" TV series, a member
of the good-guys team slipped a single 80-column IBM punch card into a
deck being run through the bad-guys' mainframe, with the result that the
entire mainframe went up in flames/explosions/smoke etc.

My favorite is a movie where someone spills coffee on the
keyboard, causing the entire building and everything in it to
turn invisible.

 

[Richard Heathfield]

I'm not going to say it, I'm not going to say it, I'm not.....

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.

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.

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