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]

Re: newbie in C

>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]]

Re: newbie in C

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]

Re: newbie in C


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" <isnot@mail.com escreveu na mensagem
news:%23lOv7KJ5 IHA.1204@TK2MSF TNGP04.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]

Re: newbie in C

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" <isnot@mail.com escreveu na mensagem
news:%23d9HQPg5 IHA.5108@TK2MSF TNGP06.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" <isnot@mail.com escreveu na mensagem
news:%23lOv7KJ5 IHA.1204@TK2MSF TNGP04.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]

Re: newbie in C

>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]

Re: newbie in C

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" <DavidL@example .invalidescreve u na mensagem
news:qako74l5fq ik4feib2n1mulnf c063c5t9a@4ax.c om...

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]

Re: newbie in C

>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]]

Re: newbie in C

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]

Re: newbie in C


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 "environmen t 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 "environmen t 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]]

Re: newbie in C

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 "environmen t 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 "environmen t 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.