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! =-----
Nov 14 '05
101  3236 
In <40**********@mk-nntp-2.news.uk.tiscali.com> "Peter Pichler" <pi*****@pobox.sk> writes: "Dan Pop" <Da*****@cern.ch> wrote in message
news:c0**********@sunnews.cern.ch...
...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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <pa****************************@spam.for.me.invali d> Nils Petter Vaskinn <no@spam.for.me.invalid> writes: 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Thu, 19 Feb 2004 13:04:38 +0000, Dan Pop wrote: 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.
In a previous post you wrote:Richard Heathfield wrote:
/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/
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.
--
NPV
"the large print giveth, and the small print taketh away"
Tom Waits - Step right up
In <pa****************************@spam.for.me.invali d> Nils Petter Vaskinn <no@spam.for.me.invalid> writes: On Thu, 19 Feb 2004 13:04:38 +0000, Dan Pop wrote:
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.
In a previous post you wrote:Richard Heathfield wrote:
/* The Windows technique - this one caused
* a disk failure on my Windows 2000 box
*/
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"
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Wed, 18 Feb 2004, [iso-8859-1] José de Paula wrote:
Em Wed, 18 Feb 2004 10:13:46 -0500, Kenneth Brody escreveu:
The following program may cause hardware damage, though the results
are not guaranteed.
void main()
{
char *pt, c;
*( pt = pt++ ) = c;
}
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
> 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.
"Bill Cunningham" <no****@nspam.net> wrote in message
news:40**********@corp.newsgroups.com... 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
Richard Heathfield <in*****@address.co.uk.invalid> wrote in message news:<40******@news2.power.net.uk>... I am not sure if you're joking or serious here. 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
In <84*************************@posting.google.com> ol*****@inspire.net.nz (Old Wolf) writes: 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.
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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes: Dan Pop wrote:
As it happens, RH didn't have a disk failure at all.
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <x6****************@lachesis.uio.no>, fo****@uio.no says... Nick Landsberg <hu*****@att.net> writes:
| Christopher Dyken wrote: Bad design of a C/perl/python/assembler/whatever program can cripple
any data the user who is running the program has access to. What means
different languages/run-time systems apply to prevent this varies. But
perl can mess up your files as easily as C. But this doesn't
physically harm your computer.
Cheers,
Chris.
| 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.
--
Randy Howard
2reply remove FOOBAR
Dan Pop wrote: In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
As it happens, RH didn't have a disk failure at all.
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.
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.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
In article <2J*******************@nwrddc01.gnilink.net>, nrk <ra*********@devnull.verizon.net> writes:
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/groups?selm...40newscene.com
2. http://groups.google.com/groups?selm...s3.newsguy.com
--
Michael Wojcik mi************@microfocus.com
Vinegar keeps more flies away than honey does.
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c0**********@sunnews.cern.ch... In <40**********@corp.newsgroups.com> "Bill Cunningham" <no****@nspam.net>
writes:I read an article in a book about Perl and Common Gateway Interface and
itmentioned C. It said that C could damage your computer. I don't know
wetherit meant the standard or compiler issuses. I was a little upset. Well
moreupset. I sent Dennis Ritchie and email. I don't know if he'll respond if
hegets it. Sometimes he does sometimes not. How can C damage your computer?
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
-----= 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! =-----
In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes: Dan Pop wrote:
In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
As it happens, RH didn't have a disk failure at all.
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.
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. Which he
chose not to address, preferring to pontificate.
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote: In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
> As it happens, RH didn't have a disk failure at all.
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.
The disk failure happened.
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.
See Message ID <40******@news2.power.net.uk>
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?)
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.
If you don't want to read what I write, don't read what I write.
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.
I have yet to see any reason why I /should/ prove it. If you choose not to
believe me, fine, don't believe me.
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.
See above.
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.
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.
It was, in short, a disk failure.
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.
Which he
chose not to address, preferring to pontificate.
So you say.
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?
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
On Tue, 24 Feb 2004 20:27:08 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote: Dan Pop wrote:
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.
I'm not going to say it, I'm not going to say it, I'm not.....
:-) It was, in short, a disk failure.
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.
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. 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?
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....
--
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 =---
On Thu, 19 Feb 2004 12:47:10 +0000, Dan Pop wrote: In <40**********@mk-nntp-2.news.uk.tiscali.com> "Peter Pichler"
<pi*****@pobox.sk> writes:
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c0**********@sunnews.cern.ch...
...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?)
Charles Sullivan <cw******@triad.rr.com> writes: 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.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield
Mark McIntyre wrote: On Tue, 24 Feb 2004 20:27:08 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote:
Dan Pop wrote:
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.
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.
It was, in short, a disk failure.
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.
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).
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Bill Cunningham wrote: How can C damage your computer?
If the computer that you programmed,
catches fire at a trade show, you will be razzed.
--
pete
In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes: Dan Pop wrote:
In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
>Dan Pop wrote:
>
>> As it happens, RH didn't have a disk failure at all.
>
>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.
The disk failure happened.
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.
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. 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.
See Message ID <40******@news2.power.net.uk>
And when asked to elaborate, you posted the text I have quoted above. 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.
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
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
-----= 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! =-----
In <40**********@corp.newsgroups.com> "Bill Cunningham" <no****@nspam.net> writes: 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes: Dan Pop wrote:
<snip>
You're changing your initial story:
<sigh> If you say so. </sigh>
I wasn't saying it, I was *proving* it.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Richard Heathfield wrote: 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
In article <5m********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:
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.
--
Michael Wojcik mi************@microfocus.com
But I still wouldn't count out the monkey - modern novelists being as
unpredictable as they are at times. -- Marilyn J. Miller
On Wed, 25 Feb 2004 06:30:23 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote: Mark McIntyre wrote:
On Tue, 24 Feb 2004 20:27:08 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote:
Dan Pop wrote:
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.
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.
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.
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,
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.
--
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 =---
On Wed, 25 Feb 2004 17:47:34 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote: Dan Pop wrote:
In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
<snip>
You're changing your initial story:
<sigh> If you say so. </sigh>
I wasn't saying it, I was *proving* it.
<sigh> If you say so. </sigh>
And now you're just being childish.
Both of you.
--
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 =---
On 25 Feb 2004 22:19:38 GMT, in comp.lang.c , mw*****@newsguy.com (Michael
Wojcik) wrote:
In article <5m********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:
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.
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.
--
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 =---
Mark McIntyre wrote: On Wed, 25 Feb 2004 06:30:23 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
On Tue, 24 Feb 2004 20:27:08 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote:
Dan Pop wrote:
> 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.
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.
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.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Mark McIntyre wrote: On Wed, 25 Feb 2004 17:47:34 +0000, in comp.lang.c , Richard Heathfield
<in*****@address.co.uk.invalid> wrote:
Dan Pop wrote:
In <40******@news2.power.net.uk> Richard Heathfield
<in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
<snip>
> You're changing your initial story:
<sigh> If you say so. </sigh>
I wasn't saying it, I was *proving* it.
<sigh> If you say so. </sigh>
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.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
On Wed, 25 Feb 2004 14:18:27 +0000, Dan Pop wrote: 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 <c0***********@sunnews.cern.ch> ). (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"
--
NPV
"the large print giveth, and the small print taketh away"
Tom Waits - Step right up
Ben Pfaff wrote: Charles Sullivan <cw******@triad.rr.com> writes:
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.
I'm drawing a blank. Which is it? I may have to go rent it.
Mark S.
Mark F. Haigh wrote: Ben Pfaff wrote:
Charles Sullivan <cw******@triad.rr.com> writes:
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.
I'm drawing a blank. Which is it? I may have to go rent it.
Mark S.
Er, Mark H.
Damn Sierra Nevada...
Mark F. Haigh mf*****@sbcglobal.net
In <c1********@enews4.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes: In article <5m********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:
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.
You have still to prove the existence of PC disks that are not immune to
this kind of abuse.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <pa****************************@spam.for.me.invali d> Nils Petter Vaskinn <no@spam.for.me.invalid> writes: On Wed, 25 Feb 2004 14:18:27 +0000, Dan Pop wrote:
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.
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 <c0***********@sunnews.cern.ch> ). (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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Mark McIntyre wrote: 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'.
--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
In article <7i********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes: On 25 Feb 2004 22:19:38 GMT, in comp.lang.c , mw*****@newsguy.com (Michael
Wojcik) 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.
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.
I have no idea how likely it is, since I haven't seen any reliable
statistics on the subject. However, there's no need for "damage [to]
the disk electronics". If the controller can be put into a mode
where BIOS is unable to detect the drive, eg by writing the proper
value to a memory-mapped port, and that mode is reset by loss of
power but not by CPU reset, that could produce the symptoms Richard
reported.
ATA, for example, defines different reset operations for Power On,
Hardware, and Software reset (see X3T 10/0948D Rev 4c 7.1). That
anticipates situations where those different reset operations would
have different effects.
--
Michael Wojcik mi************@microfocus.com
How can I sing with love in my bosom?
Unclean, immature and unseasonable salmon. -- Basil Bunting
"Mark F. Haigh" <mf*****@sbcglobal.ten> wrote in message
news:kP*******************@newssvr25.news.prodigy. com... Ben Pfaff wrote:
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.
Wasn't it "The invisible man"?
Programmer Dude wrote: Mark McIntyre wrote:
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'.
Thanks, Chris. Nice to see a little common sense breaking out there. :-)
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
In <40***************@Sonnack.com> Programmer Dude <Ch***@Sonnack.com> writes: Mark McIntyre wrote:
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'.
It's more like "disk failed to operate as expected by the BIOS this time".
Which doesn't imply a temporary disk failure any more than implies a BIOS
failure to detect and/or initialise the disk from the state it was left
into by the crashing OS.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <c1**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes: In <c1********@enews4.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:
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.
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. Whether controllers vulnerable to such symptoms
actually exist is beside the point; the question is whether it's
*possible* that they exist. If it is, then "no ring-0 code error
could cause disk controller failure" is untrue.
--
Michael Wojcik mi************@microfocus.com
This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation
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.
<mode pedant>
If you check back, you'll see that this is not what I said.
If it is, then "no ring-0 code error
could cause disk controller failure" is untrue.
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... :-)
</mode>
--
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 =---
In article <c1********@enews2.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes: 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.
It depends also quite a bit on the OS used of course. I have had a
system that had damaged the HD in such a way that the system was
unable to reboot even from CD. Also booting through the firmware
did not help. The problem was that the OS would hang at the moment
the disk was mounted, a bug in the OS. But of course there was an
initial bug that would write something on the disk that would make
the system hang. (The helpdesk of the computer-vendor of course
could not believe it was a software bug, he suspected a hardware
bug or a virus...)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
On 26 Feb 2004 18:17:54 GMT Da*****@cern.ch (Dan Pop) wrote: In <c1********@enews4.newsguy.com> mw*****@newsguy.com (Michael
Wojcik) writes:
In article <5m********************************@4ax.com>, Mark
McIntyre <ma**********@spamcop.net> writes:> 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.
You have still to prove the existence of PC disks that are not immune
to this kind of abuse.
Just for the record, at least with floppy disks if you set the first
three octets of the boot sector to the wrong values then the BIOS (at
least in the early 90s when I tested this) would fail to recognise that
the floppy existed and therefor would not allow the OS to format the
disk. Note, this includes not being able to even do a full format with
either MS DOS or DR DOS, both of which I had access to and the disk
editor in Norton Utilities would also fail to recognise that the floppy
existed. The Atari ST, on the other hand, did not care what those three
octets were so I could reset them to the expected values and suddenly
the PC would accept the floppy. I would not be surprised if the same
thing applies to HDs since those three bytes are one of the mechanisms
used to automatically load SW on accessing the disk to provide things
like compressed floppies that can be read on PCs without the disk
compression SW and, I assume, the SW provided by companies like Maxtor
to work passed BIOS limitations on HD size.
So writing three octets to a floppy could definitely cause a "failure"
that you could not used a PC to recover from and the same may well be
true (although I have not verified it) with IDE HDs (SCSII is different
because it used to be the case that to do a low level format you just
sent a command to the HD telling it to do the low level formatting of
itself, although having to do a low level format would not be nice!).
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spam, it is real and I read it.
In <c1********@enews2.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes: In article <c1**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes: In <c1********@enews4.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:
>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.
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. Whether controllers vulnerable to such symptoms
actually exist is beside the point; the question is whether it's
*possible* that they exist. If it is, then "no ring-0 code error
could cause disk controller failure" is untrue.
Until you prove their existence, Mark has all the rights to believe that
such a thing is *practically* impossible. Theoretical possibility is of
little relevance in a discussion about a thing that allegedly happened.
In theory, it is equally possible that running Richard's program made
dragons fly out of Mark's nose (but Mark didn't notice, being asleep at
the time).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: b83503104 |
last post by:
When are they not consistent?
|
by: cesark |
last post by:
Hi !
I have important doubts about how to handle the security in asp.net
vb.net web forms. Somebody can help me?
1. If you have setting ‘validateRequest=true’ in .net framework1.1,
What can...
|
by: Lee |
last post by:
Hi
Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). Is this due to the
possibility of array overflow? Is it correct that the program...
|
by: Brendan |
last post by:
Hi,
I'm trying to mimic the IPC/messaging system of an specific OS in a
portable way by using GCC's library. The IPC system uses buffered
asynchronous messages, where any thread can send a...
|
by: lovecreatesbea... |
last post by:
C stops the conversion from (char **) to (const char **). c-faq.com
sec 11.10 has explanation on this point. But, for example, even the
conversion from (char *) to (const char *) brings the same...
|
by: Thomas.li |
last post by:
Hi,
I want to convert CString to LPBYTE like
LPBYTE lpByte = (BYTE*)(LPCTSTR)cstring;
is it very dangerous to do that?
|
by: Julian |
last post by:
'evening.
I'm not new to C and have been programming in it since I was 8 but
here's a strange problem I've never seen before.
When I compile a program from our C course with a windows compiler...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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: 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...
| |
