C dangerous?

[Bill Cunningham]

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. I don't know wether
it meant the standard or compiler issuses. I was a little upset. Well more
upset. 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?

Bill

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Michael Wojcik]

In article <fv********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:

On 27 Feb 2004 22:18:59 GMT, in comp.lang.c , mw*****@newsguy.com (Michael
Wojcik) wrote:

Fortunately, no, I don't. I was merely explaining why I thought
Mark's belief that a failure in ring-0 code could not possibly put a
disk controller in a state which a software reboot would not reset
was unfounded.

If you check back, you'll see that this is not what I said.
When I wrote:

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. (<c1********@enews4.newsguy.com>)

You responded:

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. (<7i********************************@4ax.com>)

In short, I claimed that the bug could affect the controller in such
a way as to produce the symptom in question (BIOS can't access disk
until after cold boot). You contradicted me. I ignored the clause
about "damag[ing] the disk electronics", since I hadn't claimed
anything of the sort, and assumed that you disagreed with what I
had actually written.

I admit that in the message you've quoted above I suggested you were
objecting to the hypothetical controller-in-an-invalid-state
diagnosis, since that's what I had been talking about all along. If
that's not in fact what you meant, then your original objection to
my post is moot, since I never claimed any "damage to the drive
electronics".

You also wrote:

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.
(<5m********************************@4ax.com>)

and I continue to claim that you are mistaken. The issues of drive
versus controller and "damage to electronics" versus controller
state are beside the point, because "damage to drive electronics"
is not (I have claimed) the only problem that could produce the
reported symptom (disk failure reported on warm boot).
but again, thats not what I said. Please dont misquote me in the context
of a Poppian debate, its bad enough being abused about what I /did/
write... :-)

I didn't quote you at all in this case. I paraphrased, in a what I
feel was a generous manner: I interpreted your argument as relevant
to what I had actually claimed, not about some chimerical "damage to
electronics". If you prefer, I'm happy to interpret your argument
more strictly and simply note that it's irrelevant.

--
Michael Wojcik mi************@microfocus.com

When [Columbus] landed on America it was more like an evasion than a
discovery. -- Matt Walsh

[Mark McIntyre]

On 1 Mar 2004 18:28:15 GMT, in comp.lang.c , mw*****@newsguy.com (Michael
Wojcik) wrote:

In article <fv********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:

On 27 Feb 2004 22:18:59 GMT, in comp.lang.c , mw*****@newsguy.com (Michael
Wojcik) wrote:

>Fortunately, no, I don't. I was merely explaining why I thought
>Mark's belief that a failure in ring-0 code could not possibly put a
>disk controller in a state which a software reboot would not reset
>was unfounded.

If you check back, you'll see that this is not what I said.

You responded:

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. (<7i********************************@4ax.com>)

Do you see the last sentence here? Do you understand it ?
You also wrote:

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.
(<5m********************************@4ax.com>)

and I continue to claim that you are mistaken.

*shrug*. And I care because?

if you want to continue this, take it to alt.flames.hardware. I'm not
particularly interested except to remove what I felt was a
misrepresentation of what i said.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---