Hi,
Why does a C/C++ programs crash?
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
Thanks.
34  4419 
NewToCPP wrote:
Hi,
Why does a C/C++ programs crash?
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
What would you suggest as an alternative?
Normally it isn't the program that crashes, but the operating
environment that terminates the program when it attempts to access
something that doesn't belong to it. The contents of address 0 for example.
--
Ian Collins.
NewToCPP wrote:
Why does a C/C++ programs crash?
Firstly, some people post the term "C/C++" when they clearly don't know
the difference between C and C++, so we often correct them.
In this case, you are asking "Why do members of the C family of languages
crash?" That includes various Small-Cs, K&R C, Objective-C, ISO C, ARM
C++, ISO C++, GNU C, GNU C++, and so on. Each just a little different!
They all crash.
(Java and C# are not on the list. They crash for different reasons. {}
for block delimiters does not a C language make!)
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
Because the C languages were invented to compete with Assembler, which
crashes whenever you write impossible instructions for the CPU. Like
"point to protected memory", or "treat this impossible number as an opcode".
Such crashes invoke hardware protection (or less), so a C language will
simply rely on that hardware.
An assembler cannot read all your machine language opcodes and predict
which ones will cause trouble. Similarly, a C language cannot predict
which sequence of operations will crash. And a C language, by definition,
compiles rapidly to create brute-force assembly code, with very little
interpretation. Without a simple mapping between C constructs and assembly
code, those who need speed could not use a C language.
--
Phlip
NewToCPP wrote:
Hi,
Why does a C/C++ programs crash?
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
Thanks.
When the program performs such an invalid operation it is unsafe to
proceed. Letting it run would cause further damage. It's just like
having a wheel fall off a car: Do not proceed.
--
Scott McPhillips [VC++ MVP]
NewToCPP posted:
Hi,
Why does a C/C++ programs crash?
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
Thanks.
A general access fault in the second fudiciary conduit on the third branch of
the CPI routing scheme. That's your problem 99% of the time.
--
Frederick Gotham
Phlip wrote:
Firstly, some people post the term "C/C++" when they clearly don't know
the difference between C and C++, so we often correct them.
Microsoft's compiler outputs a message identifying itself as "C/C++".
Kaz Kylheku wrote:
Phlip wrote:
>>Firstly, some people post the term "C/C++" when they clearly don't know
the difference between C and C++, so we often correct them.
Microsoft's compiler outputs a message identifying itself as "C/C++".
And we all know how well they adhere to standards!
--
Ian Collins.
Ian Collins wrote:
Kaz Kylheku wrote:
>Phlip wrote:
>>>Firstly, some people post the term "C/C++" when they clearly don't know
the difference between C and C++, so we often correct them.
Microsoft's compiler outputs a message identifying itself as "C/C++".
And we all know how well they adhere to standards!
One of the most standard compliant compiler vendor (even supporting export)
uses
Comeau C/C++ (tm)
to advertise the products. Maybe, when it comes to compilers the
string "C/C++" sometimes means: a pair of two compilers (one for C and one
for C++) that produce binary compatible object files for the use with a
common linker.
Best
Kai-Uwe Bux
Ian Collins skrev:
Kaz Kylheku wrote:
Phlip wrote:
>Firstly, some people post the term "C/C++" when they clearly don't know
the difference between C and C++, so we often correct them.
Microsoft's compiler outputs a message identifying itself as "C/C++".
And we all know how well they adhere to standards!
Some of us do. They are quite standards compliant - the only serious
omission being no support for export.
/Peter
>
--
Ian Collins.
"NewToCPP" <he****@yahoo.comwrote:
Why does a C/C++ programs crash?
For the same reason cars crash: people drive them badly.
The most common error in C or C++ is illegal use of resources,
such as:
char* i; // declare pointer i, pointing to God knows what
*i = 7; // write 7 to unknown RAM address; effect unknown
But other errors can cause "crashes", such as:
double A = 3.07;
for (int i = 0; i >= 0; ++i) // runaway loop, never exits
{
A *= 1.035;
}
Or:
// In header1.h:
#include header2.h
// In header2.h:
#include header1.h // Oh, my.
(Crashes spectularly at compile time; preprocessor churns for
a long time, fills both stack and paging memory with crap,
causing system crash due to resource exhaustion. Programmer
should have used include guards.)
The list goes on.
Short answer: programs crash because people make dumb mistakes.
--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter) http://home.pacbell.net/earnur/
"Ian Collins" <ia******@hotmail.comwrote in message
news:4h*************@individual.net...
NewToCPP wrote:
>Hi,
Why does a C/C++ programs crash?
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
What would you suggest as an alternative?
Normally it isn't the program that crashes, but the operating
environment that terminates the program when it attempts to access
something that doesn't belong to it. The contents of address 0 for
example.
Well, consider this (untested) program.
int main()
{
int MyInt = 10;
int* MyIntP;
MyIntP = &MyInt;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
std::cout << MyIntP << std::endl;
*MyIntP = 30; // Got syntax right this time, but pointer is wrong
}
What would you suggest this program to do? Given the proper headers it
should compile and run as it is all legal code. But the programmer made a
mistake on one line. Instead of changing the contents of a pointer to a
value, they accidently changed the pointer itself. Then they tried to view
to the contents of the pointer, and then change the contents of the ponter.
What is the computer supposed to do? MyIntP = 20; is legal. There may be
cases where it's actually valid and is what was meant to do. But in this
case it's just wrong logically.
The next line the program is supposed to output the contents at the pointer,
but the pointer is pointing to memory the program doesn't "own". In fact,
depending on how the architecture and OS is set up, it may not even be
pointing to memory at all. What would you have the program do when it gets
to this point? On windows an error message will pop up stating that the
program attempted to read memory it doesn't "own". That is a crash. What
alternative is there?
If that last line was commented out, what would you have the next line do?
It is attempting to write to memory the program doesn't "own" Windows again
pops up with an error, this time saying the program is trying to write to
memory the program doesn't "own".
There are many reasons that the OS doesn't allow you to just write to memory
willy nilly. Mostly because it's usually a bug when you try to do so as
this shows.
Do you have an alternative? Of course, I could put in try ... catch blocks
and catch the errors in my program, but what could I do more than give my
own message saying I'm trying to use memory I don't own? The program
obvoiusly can't continue at this point, because the compiler/OS/program has
no way of knowing if the line that was trying to run was critical to the
program or not.
Jim Langston wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:4h*************@individual.net...
>>NewToCPP wrote:
>>>Hi,
Why does a C/C++ programs crash?
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
What would you suggest as an alternative?
Normally it isn't the program that crashes, but the operating
environment that terminates the program when it attempts to access
something that doesn't belong to it. The contents of address 0 for
example.
Well, consider this (untested) program.
int main()
{
int MyInt = 10;
int* MyIntP;
MyIntP = &MyInt;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
std::cout << MyIntP << std::endl;
*MyIntP = 30; // Got syntax right this time, but pointer is wrong
}
What would you suggest this program to do? Given the proper headers it
should compile and run as it is all legal code. But the programmer made a
mistake on one line. Instead of changing the contents of a pointer to a
value, they accidently changed the pointer itself. Then they tried to view
to the contents of the pointer, and then change the contents of the ponter.
What is the computer supposed to do? MyIntP = 20; is legal. There may be
cases where it's actually valid and is what was meant to do. But in this
case it's just wrong logically.
Are you replying to me or the OP?
--
Ian Collins.
"Robbie Hatley" <bo***********@no.spamwrote in message
news:KX******************@newssvr27.news.prodigy.n et...
"NewToCPP" <he****@yahoo.comwrote:
>Why does a C/C++ programs crash?
For the same reason cars crash: people drive them badly.
The most common error in C or C++ is illegal use of resources,
such as:
char* i; // declare pointer i, pointing to God knows what
*i = 7; // write 7 to unknown RAM address; effect unknown
But other errors can cause "crashes", such as:
double A = 3.07;
for (int i = 0; i >= 0; ++i) // runaway loop, never exits
{
A *= 1.035;
}
An infinite loop is not a "crash". Infinite _recursion_ would lead to a
crash, but an infinite loop simply loops. I've written programs that loop
forever (well, until I stop them anyway).
Or:
// In header1.h:
#include header2.h
// In header2.h:
#include header1.h // Oh, my.
(Crashes spectularly at compile time; preprocessor churns for
a long time, fills both stack and paging memory with crap,
causing system crash due to resource exhaustion. Programmer
should have used include guards.)
What compiler does that? VS 2003 reports "too many include files: depth =
1024". Sounds like a pretty poorly written compiler if it can't protect
itself from the data it's processing.
And compile-time problems are also not program crashes, (except perhaps in
some cases, a crash of the _compiler_ program).
The list goes on.
Short answer: programs crash because people make dumb mistakes.
There are many reasons, not just dumb mistakes. Removing a required
physical resource, hard disk problems, running out of memory, cosmic rays,
power surges, and even subtle mistakes that aren't "dumb" at all, to name a
few. Any number of things might lead the system to determine that a process
is attempting an invalid operation, and that it needs to shut down the
offending process.
-Howard
Jim Langston <ta*******@rocketmail.comwrote:
int main()
{
int MyInt = 10;
int* MyIntP;
MyIntP = &MyInt;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
std::cout << MyIntP << std::endl;
*MyIntP = 30; // Got syntax right this time, but pointer is wrong
}
What would you suggest this program to do? Given the proper headers
it should compile and run as it is all legal code. But the
[..]
What is the computer supposed to do? MyIntP = 20; is legal. There
MyIntP = 20; is not legal. The compiler will abort with an error.
hth
--
jb
(reply address in rot13, unscramble first)
Jakob Bieling wrote:
Jim Langston <ta*******@rocketmail.comwrote:
int main()
{
int MyInt = 10;
int* MyIntP;
MyIntP = &MyInt;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
What is the computer supposed to do? MyIntP = 20; is legal. There
MyIntP = 20; is not legal. The compiler will abort with an error.
There's no requirement that the compiler abort, nor is there any
requirement for an "error". The only thing the Standard requires is a
diagnostic. The compiler could go ahead and finish compiling if the
designer wanted it to.
Brian
"Howard" wrote:
"Robbie Hatley" wrote:
"NewToCPP" <he****@yahoo.comwrote:
Why does a C/C++ programs crash?
For the same reason cars crash: people drive them badly.
The most common error in C or C++ is illegal use of resources,
such as:
char* i; // declare pointer i, pointing to God knows what
*i = 7; // write 7 to unknown RAM address; effect unknown
But other errors can cause "crashes", such as:
double A = 3.07;
for (int i = 0; i >= 0; ++i) // runaway loop, never exits
{
A *= 1.035;
}
An infinite loop is not a "crash".
That's like saying, "your car caught fire and burned up, Mr. Smith,
so we're sorry, but we can't pay on your claim; you're only insured
against actual CRASHES, not fires". In other words, it crashed.
Infinite _recursion_ would lead to a crash, but an infinite
loop simply loops. I've written programs that loop
forever (well, until I stop them anyway).
Yes: Firmware, and Microsoft Windows apps both "loop forever";
but the loop I demonstrated doesn't just "loop forever", it
does so in a way that precludes input, output, or breaking
out. You generally have to push the "Reset" button. In other
words, it crashed.
(I inadvertantly did that to an IBM 370 for an entire half hour
once. Boy was the sysop annoyed when he discovered the the
entire system had been doing nothing but running my loop for
30 minutes. Good thing they didn't charge me for the CPU time.)
Or:
// In header1.h:
#include header2.h
// In header2.h:
#include header1.h // Oh, my.
(Crashes spectularly at compile time; preprocessor churns for
a long time, fills both stack and paging memory with crap,
causing system crash due to resource exhaustion. Programmer
should have used include guards.)
What compiler does that?
VS 2003 reports "too many include files: depth = 1024".
Sounds like a pretty poorly written compiler if it can't
protect itself from the data it's processing.
The situation I describe will crash the preprocessor.
The program will never get to the compiler.
Compilers never see #include's. The preprocessor replaces
those (if it can) with the contents being #include'ed. If
it can't, it crashes, and the compiler never runs.
And compile-time problems are also not program crashes.
That's like saying, "I'm sorry, but we can't pay on your claim
because you crashed your car while it was still inside the car
lot you bought it from." In other words, it crashed.
The list goes on.
Short answer: programs crash because people make dumb mistakes.
There are many reasons, not just dumb mistakes. Removing a
required physical resource
Two people made dumb mistakes there: The person who removed
the resource, and the person who made the program so brittle
that the missing resource triggered a crash.
hard disk problems
The user slammed the door into the computer, or the HD engineer
designed a flaky product. In other words, dumb mistakes.
running out of memory
The user ran a resource-hungry program on a machine with only
8MB of RAM. Dumb mistake.
cosmic rays
In other words, someone made a dumb mistake, and cosmic rays
seemed a good thing to blame. :-)
power surges
User forgot to use a surge protector and an UPS, and left his
machine running during a thunderstorm. Dumb mistake.
and even subtle mistakes that aren't "dumb" at all,
Yes, some mistakes are subtle. But most are more along
the lines of "what idiot wrote this stupid code??? Oh,
wait, that was me. Oops. How could I have made such
a dumb mistake?"
Any number of things might lead the system to determine
that a process is attempting an invalid operation,
and that it needs to shut down the offending process.
Yes, and nearly ALL of those "number of things" are do to
human error on someone's part. Not necessarily the programmer,
but usually so. Face it: to err is human; but to really foul
things up requires a computer and someone who believes they're
an expert (but who is really just a pert). ;-)
--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter) http://home.pacbell.net/earnur/
Robbie Hatley wrote:
>
"Howard" wrote:
An infinite loop is not a "crash".
That's like saying, "your car caught fire and burned up, Mr. Smith,
so we're sorry, but we can't pay on your claim; you're only insured
against actual CRASHES, not fires". In other words, it crashed.
A poor protest. Indeed, a fire is not a crash, which is why it's
normally covered under the comprehensive portion of your policy, not
the collision.
Likewise, a hang is not crash in computer programs. If you think they
are, then you're rather badly mistaken.
Brian
Default User <de***********@yahoo.comwrote:
Jakob Bieling wrote:
>Jim Langston <ta*******@rocketmail.comwrote:
>>int main()
{
int MyInt = 10;
int* MyIntP;
MyIntP = &MyInt;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
>>What is the computer supposed to do? MyIntP = 20; is legal. There
> MyIntP = 20; is not legal. The compiler will abort with an error.
There's no requirement that the compiler abort, nor is there any
requirement for an "error". The only thing the Standard requires is a
diagnostic. The compiler could go ahead and finish compiling if the
designer wanted it to.
Oh, I did not know, thanks. Can you point me to the corresponding
paragraph in the Standard? 4.7 and 4.10 do not seem to cover this.
regards
--
jb
(reply address in rot13, unscramble first)
Jakob Bieling wrote:
Default User <de***********@yahoo.comwrote:
Jakob Bieling wrote:
>Jim Langston <ta*******@rocketmail.comwrote:
int main()
{
int MyInt = 10;
int* MyIntP;
MyIntP = &MyInt;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
What is the computer supposed to do? MyIntP = 20; is legal.
There
MyIntP = 20; is not legal. The compiler will abort with an error.
There's no requirement that the compiler abort, nor is there any
requirement for an "error". The only thing the Standard requires is
a diagnostic. The compiler could go ahead and finish compiling if
the designer wanted it to.
Oh, I did not know, thanks. Can you point me to the corresponding
paragraph in the Standard? 4.7 and 4.10 do not seem to cover this.
Probably not. Which section mandates the compiler aborting?
Brian
C/C++ Programs can crash because of poor coding.
A question which I would like to ask is (to you)...
What OS are you using?
- wrote:
C/C++ Programs can crash because of poor coding.
A question which I would like to ask is (to you)...
What OS are you using?
Who are you talking to, and about what? Please quote the relevant
portion of the previous message. Google now does that automatically, so
you have little excuse.
Brian
Default User <de***********@yahoo.comwrote:
Jakob Bieling wrote:
>Default User <de***********@yahoo.comwrote:
>>Jakob Bieling wrote:
>>>Jim Langston <ta*******@rocketmail.comwrote:
>>>>int* MyIntP;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
>>> MyIntP = 20; is not legal. The compiler will abort with an error.
>>There's no requirement that the compiler abort, nor is there any
requirement for an "error". The only thing the Standard requires is
a diagnostic. The compiler could go ahead and finish compiling if
the designer wanted it to.
> Oh, I did not know, thanks. Can you point me to the corresponding
paragraph in the Standard? 4.7 and 4.10 do not seem to cover this.
Probably not. Which section mandates the compiler aborting?
I have not found any section that explicitly _mandates_ it. But I
did find those above sections about conversions. Now, maybe I did not
look at the right pages, but I could not find anything saying a
conversion from int to pointer (a pointer to int, specifically) was
legal, except for an int being 0 (simplified quote, see 4.10/1).
If the Standard does indeed not mention it anywhere, then I conclude
this is undefined behaviour. Thus, the compiler could silently ignore it
and not "abort with an error." On the other hand, you said a diagnostic
is required. Why?
regards
--
jb
(reply address in rot13, unscramble first)
In article <e8***********@f1node01.rhrz.uni-bonn.de>, ar****************@rot13.com says...
[ ... ]
I have not found any section that explicitly _mandates_ it. But I
did find those above sections about conversions. Now, maybe I did not
look at the right pages, but I could not find anything saying a
conversion from int to pointer (a pointer to int, specifically) was
legal, except for an int being 0 (simplified quote, see 4.10/1).
If the Standard does indeed not mention it anywhere, then I conclude
this is undefined behaviour. Thus, the compiler could silently ignore it
and not "abort with an error." On the other hand, you said a diagnostic
is required. Why?
4/1: Standard conversions are implicit conversions defined for built-
in types. Clause 4 enumerates the full set of such conversions.
4/3: An expression e can be implicitly converted to a type T if and
only if the declaration “T t=e;” is well-formed, for some invented
temporary variable t (8.5).
1.4/1: The set of diagnosable rules consists of all syntactic and
semantic rules in this International Standard except for those rules
containing an explicit notation that “no diagnostic is required” or
which are described as resulting in “undefined behavior.”
1.4/2: If a program contains a violation of any diagnosable rule, a
conforming implementation shall issue at least one diagnostic
message...
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jakob Bieling wrote:
Default User <de***********@yahoo.comwrote:
Probably not. Which section mandates the compiler aborting?
I have not found any section that explicitly mandates it.
That's right. The Standard has a number of situations and conditions
where it requires a diagnostic. I'm unaware of any section that
mandates that compilation stop.
A "diagnostic" can be almost anything the compiler desiger wants.
That's strictly QOI.
Brian
Jerry Coffin <jc*****@taeus.comwrote:
In article <e8***********@f1node01.rhrz.uni-bonn.de>,
ar****************@rot13.com says...
[ ... ]
> I have not found any section that explicitly _mandates_ it. But I
did find those above sections about conversions. Now, maybe I did not
look at the right pages, but I could not find anything saying a
conversion from int to pointer (a pointer to int, specifically) was
legal, except for an int being 0 (simplified quote, see 4.10/1).
If the Standard does indeed not mention it anywhere, then I
conclude this is undefined behaviour. Thus, the compiler could
silently ignore it and not "abort with an error." On the other hand,
you said a diagnostic is required. Why?
4/1: Standard conversions are implicit conversions defined for built-
in types. Clause 4 enumerates the full set of such conversions.
4/3: An expression e can be implicitly converted to a type T if and
only if the declaration “T t=e;” is well-formed, for some invented
temporary variable t (8.5).
1.4/1: The set of diagnosable rules consists of all syntactic and
semantic rules in this International Standard except for those rules
containing an explicit notation that “no diagnostic is required” or
which are described as resulting in “undefined behavior.”
1.4/2: If a program contains a violation of any diagnosable rule, a
conforming implementation shall issue at least one diagnostic
message...
So in essence, the posted code snippet produces undefined behaviour
for which a diagnostic message is required?
regards
--
jb
(reply address in rot13, unscramble first)
Default User <de***********@yahoo.comwrote:
Jakob Bieling wrote:
>Default User <de***********@yahoo.comwrote:
>>Probably not. Which section mandates the compiler aborting?
>I have not found any section that explicitly mandates it.
That's right. The Standard has a number of situations and conditions
where it requires a diagnostic. I'm unaware of any section that
mandates that compilation stop.
Yip, should have been more careful with my wording regarding the
compilation stop. My original reply was supposed to focus on the
undefinedness of that code snippet, which I see now you seem to agree
with.
regards
--
jb
(reply address in rot13, unscramble first)
In article <e8**********@f1node01.rhrz.uni-bonn.de>, ar****************@rot13.com says...
[ ... ]
So in essence, the posted code snippet produces undefined behaviour
for which a diagnostic message is required?
No -- it is a ill-formed code for which a diagnostic is required.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Robbie Hatley <bo***********@no.spamwrote:
>
"Howard" wrote:
>An infinite loop is not a "crash".
That's like saying, "your car caught fire and burned up, Mr. Smith,
so we're sorry, but we can't pay on your claim; you're only insured
against actual CRASHES, not fires". In other words, it crashed.
It's more like saying, "Your car is still running but can only drive
around in circles. However, the car is still (nominally) driveable and
did not crash, so no claim for you."
>And compile-time problems are also not program crashes.
That's like saying, "I'm sorry, but we can't pay on your claim
because you crashed your car while it was still inside the car
lot you bought it from." In other words, it crashed.
It's more like, "I'm sorry, but we can't pay on your claim because you
do not yet own the car." If a program doesn't compile, there is no
program that can crash.
>hard disk problems
The user slammed the door into the computer, or the HD engineer
designed a flaky product. In other words, dumb mistakes.
HDDs are mechanical devices, subject to the laws of thermodynamics.
There are no perpetual motion machines. All hard drives will eventually
fail. Of course, if you are "not dumb" enough to make a hard drive that
will never fail, you stand to make a lot of money :-)
>cosmic rays
In other words, someone made a dumb mistake, and cosmic rays
seemed a good thing to blame. :-)
Modern computers operate based on (magnetic) field effect transistors.
Occasionally a cosmic ray will have enough energy to alter the magnetic
field and spontaneously flip a bit somewhere in the computer.
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
In message <e9**********@news-int2.gatech.edu>, Marcus Kwok
<ri******@gehennom.invalidwrites
[off-topic, but let's not propagate too many misconceptions...]
>
Modern computers operate based on (magnetic) field effect transistors.
What is a "magnetic field effect transistor"? The "field" in
"field-effect transistor" refers to the _electric_ field between gate
and channel. http://en.wikipedia.org/wiki/Field_effect_transistor
>Occasionally a cosmic ray will have enough energy to alter the magnetic
field and spontaneously flip a bit somewhere in the computer.
Dynamic memory operates by storing electric charge in a potential well. http://en.wikipedia.org/wiki/Dynamic_RAM
Occasionally a cosmic ray neutron will induce a decay producing an alpha
particle and a couple of electrons, which can tip the balance of the
stored charge and cause a bit error. http://en.wikipedia.org/wiki/Soft_error
--
Richard Herring
Richard Herring <ju**@[127.0.0.1]wrote:
In message <e9**********@news-int2.gatech.edu>, Marcus Kwok
<ri******@gehennom.invalidwrites
[off-topic, but let's not propagate too many misconceptions...]
>>
Modern computers operate based on (magnetic) field effect transistors.
What is a "magnetic field effect transistor"? The "field" in
"field-effect transistor" refers to the _electric_ field between gate
and channel.
http://en.wikipedia.org/wiki/Field_effect_transistor
>>Occasionally a cosmic ray will have enough energy to alter the magnetic
field and spontaneously flip a bit somewhere in the computer.
Dynamic memory operates by storing electric charge in a potential well.
http://en.wikipedia.org/wiki/Dynamic_RAM
Occasionally a cosmic ray neutron will induce a decay producing an alpha
particle and a couple of electrons, which can tip the balance of the
stored charge and cause a bit error.
http://en.wikipedia.org/wiki/Soft_error
OK, thanks. This was written off the top of my head in a hurry, and
it's been a while since I had my microelectronics classes...
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
Marcus Kwok wrote:
Richard Herring <ju**@[127.0.0.1]wrote:
>In message <e9**********@news-int2.gatech.edu>, Marcus Kwok
<ri******@gehennom.invalidwrites
[off-topic, but let's not propagate too many misconceptions...]
>>Modern computers operate based on (magnetic) field effect transistors.
What is a "magnetic field effect transistor"? The "field" in
"field-effect transistor" refers to the _electric_ field between gate
and channel.
<OT>
Although the FETs in computers are E-field based there are M-field based FETs
See: http://www.physics.gatech.edu/people...t_al2003_4.pdf
</OT>
>>
http://en.wikipedia.org/wiki/Field_effect_transistor
>>Occasionally a cosmic ray will have enough energy to alter the magnetic
field and spontaneously flip a bit somewhere in the computer.
Dynamic memory operates by storing electric charge in a potential well.
http://en.wikipedia.org/wiki/Dynamic_RAM
Occasionally a cosmic ray neutron will induce a decay producing an alpha
particle and a couple of electrons, which can tip the balance of the
stored charge and cause a bit error.
http://en.wikipedia.org/wiki/Soft_error
OK, thanks. This was written off the top of my head in a hurry, and
it's been a while since I had my microelectronics classes...
In message <91**************************@msgid.meganewsserver s.com>,
Christopher Hulbert <cc**********@gmail.comwrites
>Marcus Kwok wrote:
>Richard Herring <ju**@[127.0.0.1]wrote:
>>In message <e9**********@news-int2.gatech.edu>, Marcus Kwok
<ri******@gehennom.invalidwrites
[off-topic, but let's not propagate too many misconceptions...]
Modern computers operate based on (magnetic) field effect transistors.
What is a "magnetic field effect transistor"? The "field" in
"field-effect transistor" refers to the _electric_ field between gate
and channel.
<OT>
Although the FETs in computers are E-field based there are M-field based FETs
See:
http://www.physics.gatech.edu/people...gurzhi_et_al20
03_4.pdf
</OT>
<OT++The word "proposed" features largely in that document ;-) </OT++>
--
Richard Herring
Richard Herring wrote:
In message <91**************************@msgid.meganewsserver s.com>,
Christopher Hulbert <cc**********@gmail.comwrites
>Marcus Kwok wrote:
>>Richard Herring <ju**@[127.0.0.1]wrote:
In message <e9**********@news-int2.gatech.edu>, Marcus Kwok
<ri******@gehennom.invalidwrites
[off-topic, but let's not propagate too many misconceptions...]
Modern computers operate based on (magnetic) field effect transistors.
What is a "magnetic field effect transistor"? The "field" in
"field-effect transistor" refers to the _electric_ field between gate
and channel.
<OT>
Although the FETs in computers are E-field based there are M-field
based FETs
See:
http://www.physics.gatech.edu/people...gurzhi_et_al20
03_4.pdf
</OT>
<OT++The word "proposed" features largely in that document ;-) </OT++>
Yes, I guess I should have said "there is MFET research" where research is the
keyword. Until this thread I don't think I've ever even heard of MFETs even in
concept!
Christopher Hulbert <cc**********@gmail.comwrote:
Yes, I guess I should have said "there is MFET research" where research is the
keyword. Until this thread I don't think I've ever even heard of MFETs even in
concept!
Maybe I'm just ahead of the curve :-)
OK, I think that's enough of this OT stuff. Sorry for the digression...
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
"Ian Collins" <ia******@hotmail.comwrote in message
news:4h**************@individual.net...
Jim Langston wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:4h*************@individual.net...
>>>NewToCPP wrote:
Hi,
Why does a C/C++ programs crash?
When there is access to a null pointer or some thing like that programs
crash, but why do they crash?
What would you suggest as an alternative?
Normally it isn't the program that crashes, but the operating
environment that terminates the program when it attempts to access
something that doesn't belong to it. The contents of address 0 for
example.
Well, consider this (untested) program.
int main()
{
int MyInt = 10;
int* MyIntP;
MyIntP = &MyInt;
MyIntP = 20; // Ooops, meant *MyIntP = 20 here
std::cout << MyIntP << std::endl;
*MyIntP = 30; // Got syntax right this time, but pointer is wrong
}
What would you suggest this program to do? Given the proper headers it
should compile and run as it is all legal code. But the programmer made
a
mistake on one line. Instead of changing the contents of a pointer to a
value, they accidently changed the pointer itself. Then they tried to
view
to the contents of the pointer, and then change the contents of the
ponter.
What is the computer supposed to do? MyIntP = 20; is legal. There may
be
cases where it's actually valid and is what was meant to do. But in this
case it's just wrong logically.
Are you replying to me or the OP?
Was meant for the OP. Sorry, I replied to the wrong message. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Blankdraw |
last post by:
Both the programs below fail to run on a Windows DOS window, after
build by MVC/C++ 4.2. No compiler problems, they just refuse to give
me anything but:
"Cannot open input file". Can someone...
|
by: hugo27 |
last post by:
hugo27 July 13, 2004
>
>The teachy books and documentation I've read do not
>mention the Escape key, but everytime I hit it during
>runtime my programs go bananas.
>
>This relates to a larger...
|
by: Suyog_Linux |
last post by:
I wish to know how the free()function knows how much memory to be
freed as we only give pointer to allocated memory as an argument to
free(). Does system use an internal variable to store allocated...
|
by: Henrik Dahl |
last post by:
Hello!
I've got many programs which crash with the execution engine exception as
they're executed by IEExec. If the programs are executed using the ordinary
host for the CLR, everything works as...
|
by: Michi Henning |
last post by:
Hi,
I'm using a blocking Select() call on a socket with
a timeout value of -1. I'd expect the call to block
indefinitely, but it doesn't. When I use Poll() instead,
a timeout of -1 works fine...
|
by: sgadag |
last post by:
Even if "a" is NULL in the assignment below, this assignment does not
cause any AV:
SOME_PTR * someVar = (SOME_PTR *) a->b;
But something like this will cause an AV because "someVar" is...
|
by: J.P. |
last post by:
Hi,
I'm having an issue after IE7 is installed on a work station, programs
set to run in full trust over the intranet are crashing. I've tried
adding the machines where the programs reside to...
|
by: samslists |
last post by:
So I have a python program that runs a bunch of other programs....it
then loops forever, occasionally executing other programs.
To run each of these programs my python code executes:...
|
by: Sh4wn |
last post by:
Hi,
first, python is one of my fav languages, and i'll definitely keep
developing with it. But, there's 1 one thing what I -really- miss:
data hiding. I know member vars are private when you...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
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: 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: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
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...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
