newbie in C

[sd]

Hi group,
lets suppose you do the following

int x;
int * ptr;
prt = &x;

without assigning any value to x

but you do this all within a compiler running on a virtual machine,
do this can damage the physical machine ?

thanks in advance, Carlos.

[David Lowndes]

>lets suppose you do the following

>
int x;
int * ptr;
prt = &x;

without assigning any value to x

but you do this all within a compiler running on a virtual machine,
do this can damage the physical machine ?

No. And neither can it "damage" the virtual machine - or the process
the code runs in.

Is this a trick question?

Dave

[Ben Voigt [C++ MVP]]

sd wrote:

Hi group,
lets suppose you do the following

int x;
int * ptr;
prt = &x;

without assigning any value to x

So far everything is just fine, once you fix the misspelled identifier (i.e.
compiler will tell you that prt is not defined, because you have a variable
named ptr but not prt).

If you were to do:

printf("%d\n", *ptr);

you would get a random value (not crypto random though, it may be very
easily predictable, but not by the C++ standard), but still you won't harm
the computer at all.

>
but you do this all within a compiler running on a virtual machine,
do this can damage the physical machine ?

thanks in advance, Carlos.

[sd]

excuseme, i m learning this crazy things

int * ptr;
ptr = 65;

now this mistake looks ok
this way ptr doesnt point
to any variable

of course, I do this inside a VM.
do this can damage the physical
machine ?.

thanks very much, Carlos.



"sd" <is***@mail.comescreveu na mensagem
news:%2****************@TK2MSFTNGP04.phx.gbl...

>
Hi group,
lets suppose you do the following

int x;
int * ptr;
prt = &x;

without assigning any value to x

but you do this all within a compiler running on a virtual machine,
do this can damage the physical machine ?

thanks in advance, Carlos.

[sd]

another "related" question,

what if I do such a mistake
in a physical machine.
do this can be "repaired"
by reinstalling windows
completelly?, i.e,
formationg hard disk and
installing Windows ?

thanks, Carlos.

"sd" <is***@mail.comescreveu na mensagem
news:%2****************@TK2MSFTNGP06.phx.gbl...

>
excuseme, i m learning this crazy things

int * ptr;
ptr = 65;

now this mistake looks ok
this way ptr doesnt point
to any variable

of course, I do this inside a VM.
do this can damage the physical
machine ?.

thanks very much, Carlos.



"sd" <is***@mail.comescreveu na mensagem
news:%2****************@TK2MSFTNGP04.phx.gbl...

>>
Hi group,
lets suppose you do the following

int x;
int * ptr;
prt = &x;

without assigning any value to x

but you do this all within a compiler running on a virtual machine,
do this can damage the physical machine ?

thanks in advance, Carlos.

[David Lowndes]

>what if I do such a mistake

>in a physical machine.

Your code:

int * ptr;
ptr = 65;

Doesn't do anything.

I assume you meant to write something more like:

int * ptr;
*ptr = 65;

Which would attempt to write to a random location.

In modern Windows this won't affect anything other than the process
running your code (which might crash). It won't affect hardware
(virtual or real).

Dave

[sd]

thanks Dave,

Please permit to me to be exceptic, how do u know this?
"In modern Windows this won't affect anything other than the process
running your code (which might crash) "

Carlos.

"David Lowndes" <Da****@example.invalidescreveu na mensagem
news:qa********************************@4ax.com...

what if I do such a mistake
in a physical machine.

Your code:

int * ptr;
ptr = 65;

Doesn't do anything.

I assume you meant to write something more like:

int * ptr;
*ptr = 65;

Which would attempt to write to a random location.

In modern Windows this won't affect anything other than the process
running your code (which might crash). It won't affect hardware
(virtual or real).

Dave

[David Lowndes]

>Please permit to me to be exceptic, how do u know this?

>"In modern Windows this won't affect anything other than the process
running your code (which might crash) "

The hardware/OS isolates each process, so unless your code is running
as a kernel driver (which I presume it's not), it can't affect other
processes or the real hardware.

Dave

[Ben Voigt [C++ MVP]]

David Lowndes wrote:

>Please permit to me to be exceptic, how do u know this?

>"In modern Windows this won't affect anything other than the process
running your code (which might crash) "

The hardware/OS isolates each process, so unless your code is running
as a kernel driver (which I presume it's not), it can't affect other
processes or the real hardware.

This is of course true in general but it's possible to devise exceptions to
the rule. For example, if another thread is writing a file meanwhile, when
your app crashes you will get a half-written file, which in turn could
affect other programs.

The point is that the MMU hardware prevents direct effects on other
processes. Secondary effects are left to the progammer to ensure
correctness.

>
Dave

[Carlos]

Hi

" For example, if another thread is writing a file meanwhile, when

your app crashes you will get a half-written file, which in turn could
affect other programs."

Perhaps such rupture could affect only its execution thread,
it should depend only on internal details of Windows. For example,
perhaps a thread really define its "environment activity", not only
refered to memory issues but also to any other related thing this
thread could affect.

IMHO, I believe there must exist mechanisms of protection in this sense,
otherwise a thread crash and its "environment activity" should be a very
dangerous threat for any running process.

Of course, all these rises the question about, what do things like

"safe threading"

really mean ?

Greetings, Carlos.

>The hardware/OS isolates each process, so unless your code is running
as a kernel driver (which I presume it's not), it can't affect other
processes or the real hardware.

This is of course true in general but it's possible to devise exceptions
to the rule. For example, if another thread is writing a file meanwhile,
when your app crashes you will get a half-written file, which in turn
could affect other programs.

The point is that the MMU hardware prevents direct effects on other
processes. Secondary effects are left to the progammer to ensure
correctness.

>>
Dave

[Ben Voigt [C++ MVP]]

Carlos wrote:

Hi

" For example, if another thread is writing a file meanwhile, when

>your app crashes you will get a half-written file, which in turn
could affect other programs."

Perhaps such rupture could affect only its execution thread,
it should depend only on internal details of Windows. For example,
perhaps a thread really define its "environment activity", not only
refered to memory issues but also to any other related thing this
thread could affect.

The only way to ensure that a thread's activity isn't left partially
completed is to never start the activity at all.

>
IMHO, I believe there must exist mechanisms of protection in this
sense, otherwise a thread crash and its "environment activity" should
be a very dangerous threat for any running process.

There are mechanisms, on a task-specific basis. For example, you can use an
ACID database to prevent the example problem I mentioned.

But some things just can't be made atomic.