newbie in C

  • Thread starter Thread starter sd
  • Start date Start date
S

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.
 
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 ?
Click to expand...

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

Is this a trick question?

Dave
 
sd said:
Hi group,
lets suppose you do the following

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

without assigning any value to x
Click to expand...

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.
 
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.
 
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.
 
what if I do such a mistake
in a physical machine.
Click to expand...

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
 
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.
 
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) "
Click to expand...

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
 
David said:
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.
Click to expand...

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.
 
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."
Click to expand...

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.
 
Carlos said:
Hi

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

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.
Click to expand...

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.
Click to expand...

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.
 
Back
Top