13 Replies - 570 Views - Last Post: 30 January 2019 - 10:21 AM Rate Topic: -----

#1 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 86
  • Joined: 11-November 18

About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 12:28 AM

Are pointers really dangerous when not used properly? What can happen if you misuse a pointer? Like for example could you crash your system?

But, how are pointers harmful if the program is allocated its own virtual memory? If it were then the pointer wouldn't be able to interfere with other programs.. so why do we say that pointers are dangerous?

Another question, can you know if a pointer is pointing to dynamically allocated, statically allocated or unallocated memory?

Is This A Good Question/Topic? 0
  • +

Replies To: About pointers (being able to access unallocated memory)

#2 german-one   User is offline

  • New D.I.C Head
  • member icon

Reputation: 14
  • View blog
  • Posts: 40
  • Joined: 05-August 18

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 01:58 AM

The pointers values you are facing are already virtualized addresses. That means the operating system assignes certain address spaces to your process and takes care you don't violate them. They are never the real, say, hardware addresses. Thus, the risk to damage something is quite low. As soon as you try to access unallocated space the OS triggers a segmentation fault and your process will die.
In general you can't distinguish if an address is valid or not. Although if you output the adresses you'll find some patterns that indicate it. However, always initialize pointer variables preferably with NULL to have a defined error status rather than values that point to nowhere.

This post has been edited by german-one: 29 January 2019 - 01:58 AM

Was This Post Helpful? 0
  • +
  • -

#3 jimblumberg   User is online

  • member icon

Reputation: 5668
  • View blog
  • Posts: 17,402
  • Joined: 25-December 09

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 06:48 AM

Quote

The pointers values you are facing are already virtualized addresses. That means the operating system assignes certain address spaces to your process and takes care you don't violate them.They are never the real, say, hardware addresses. Thus, the risk to damage something is quite low. As soon as you try to access unallocated space the OS triggers a segmentation fault and your process will die.

This is only true with modern Operating Systems and even then this is only true if you're not writing things like device drivers. It is even possible to be writing programs for something that has no OS in which case there is nothing to prevent anything from happening and in this case the address could be pointing to some hardware register. Be careful about making assumptions when dealing with the C/C++ language they were designed to be close to the hardware with little or no safety nets and the ability to talk directly to the hardware.


Quote

Are pointers really dangerous when not used properly?

Yes they can be under certain cases.

Quote

What can happen if you misuse a pointer? Like for example could you crash your system?

Again under certain circumstances, anything can happen even damage to the hardware.

Quote

But, how are pointers harmful if the program is allocated its own virtual memory?

Not everything has virtual memory, although most of the modern (post DOS) OS do use virtual memory and don't allow direct access to hardware. But thinking that you always have these safe guards is very dangerous, always treat pointers with respect and care.

Quote

Another question, can you know if a pointer is pointing to dynamically allocated, statically allocated or unallocated memory?

If you created the pointer then you should know if you allocated the memory for that pointer. But no there is no way for the program to know the status of the pointer, unless you have physically assigned the pointer to NULL otherwise the pointer is pointing to what could a valid memory location.

You really should avoid pointers whenever possible, especially in C++ where there are quite often better ways of dealing with things.


Jim
Was This Post Helpful? 1
  • +
  • -

#4 baavgai   User is offline

  • Dreaming Coder
  • member icon


Reputation: 7378
  • View blog
  • Posts: 15,309
  • Joined: 16-October 07

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 07:21 AM

In the bad old days of DOS, games were actually written using pointers to memory you weren't really supposed to access. You'd literally change the values in memory where the screen was refreshed from. This technique, called direct screen writes, was so very effective that folks refused to even consider something like Windows for games; an OS that blocked such things. This is where the "direct" in DirectX comes from, btw. Windows created a OS pathway to mimic the method DOS allowed and effectively killed DOS right then and there.

At some level, a computer simply reflects the current state of its memory. A normal program should only see the bits of memory it's allowed to see. However, consider the mischief a program could get into if it could see memory of running other programs. And, also, that for certain types of programs, such access might even be required. (e.g. virus protection. )

It can get even nastier if you can write to memory that's not yours. That little bit of the OS that handles the keyboard? Rather than ending the call after a keypress, why don't you just jump over to my bit of code and tell me what you did. How do you plug in such malicious code? You write to a part of memory you're not supposed access.
Was This Post Helpful? 2
  • +
  • -

#5 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 86
  • Joined: 11-November 18

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 08:38 AM

Quote

And, also, that for certain types of programs, such access might even be required. (e.g. virus protection. )


Yah so how are third party anti virus software able to access RAM that is out of its virtual memory?
Was This Post Helpful? 0
  • +
  • -

#6 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6717
  • View blog
  • Posts: 22,931
  • Joined: 05-May 12

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 09:45 AM

Traditionally some Windows AV's would install a kernel mode device driver (as opposed to a user mode device driver). Kernel mode device drivers have a lot more privileges.

Also a lot of AV's grant themselves process debug rights so that they can inspect the memory of running programs just like a normal debugger can.

Some AV's actually do DLL injection on Windows. Yes, where in the past DLL injection was a blackhat tool, now even the whitehats use it to. You should see what happens on some hardened systems when McAfee DLL injects itself into Internet Explorer, and IE does a self-check to make sure that nobody has injected something into it -- it's not pretty.
Was This Post Helpful? 0
  • +
  • -

#7 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6717
  • View blog
  • Posts: 22,931
  • Joined: 05-May 12

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 11:10 AM

And before our OP asks, I'll ask for him: Why is this common C/C++ idiom legal?
int * array = new int[10];
int * start = &array[0];
int * end = &array[10];    // 10 is beyond allocated memory

for( ; start < end; ++start)
    *start = 0xbaad;



(As I recall there is a discussion regarding this in the C++ FAQ forum, but my Google-fu is failing me right now.)
Was This Post Helpful? 0
  • +
  • -

#8 baavgai   User is offline

  • Dreaming Coder
  • member icon


Reputation: 7378
  • View blog
  • Posts: 15,309
  • Joined: 16-October 07

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 01:23 PM

View PostNwb, on 29 January 2019 - 10:38 AM, said:

Yah so how are third party anti virus software able to access RAM that is out of its virtual memory?

Depends on the OS. If there is a common task the requires special privileges, the OS will need to provide some API for it. Think DirectX.

e.g. for Windows and virus stuff: Antimalware Scan Interface
Was This Post Helpful? 1
  • +
  • -

#9 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6717
  • View blog
  • Posts: 22,931
  • Joined: 05-May 12

Re: About pointers (being able to access unallocated memory)

Posted 29 January 2019 - 03:19 PM

Notice that API is only for Win10 and Server 2016. For older Windows versions, the AV makers had to come up with their own ways of getting access.
Was This Post Helpful? 0
  • +
  • -

#10 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 86
  • Joined: 11-November 18

Re: About pointers (being able to access unallocated memory)

Posted 30 January 2019 - 04:06 AM

Quote

And before our OP asks, I'll ask for him: Why is this common C/C++ idiom legal

What idiom? The snippet? Is that snippet supposed to be illegal? I don't get it.. Why? BUT WHYYYY? :butbut:/>/>/>/>/>

I ran it by changing the *start = 0xbaad; to cout << *start
12255424
12260696
0
0
0
0
0
0
0
0

Is that supposed to be abnormal? I donno. :sweatdrop:/>/>

Anyways. Is it guaranteed that the first variable declared in stack would occupy the first byte of memory? So from that point if I go say 1MB locations away, I would be out of stack.

So could I use this to know whether a pointer is pointing to the stack of heap? I know it has not use but I'm just curiouss.

And also, is it possible that when I deallocate memory, the data in the memory still remains? If it is, then is it guaranteed?

Also why can't we allocate stack memory at run time if allocating from stack is actually faster than allocating from heap?

This post has been edited by Nwb: 30 January 2019 - 04:10 AM

Was This Post Helpful? 0
  • +
  • -

#11 jimblumberg   User is online

  • member icon

Reputation: 5668
  • View blog
  • Posts: 17,402
  • Joined: 25-December 09

Re: About pointers (being able to access unallocated memory)

Posted 30 January 2019 - 06:40 AM

Quote

Is it guaranteed that the first variable declared in stack would occupy the first byte of memory?

No.

Quote

So from that point if I go say 1MB locations away, I would be out of stack.

Possibly, but the size of the stack is an implementation detail on most desktop systems. But many embedded processors have stack sizes much smaller that a megabyte, on some systems you may only have a few hundred bytes to a few thousand bytes.

Quote

So could I use this to know whether a pointer is pointing to the stack of heap?

No.

Quote

And also, is it possible that when I deallocate memory, the data in the memory still remains?

The actual values held in memory don't change when you deallocate memory. However those values can be overwritten at any time.

Quote

Also why can't we allocate stack memory at run time if allocating from stack is actually faster than allocating from heap?

What are you talking about? Manually allocating memory maybe slower but I doubt that you will really be able to tell the difference. By the way do you realize the global and static qualified variables use the heap? Also don't forget "heap" and "stack" are implementation details, and one or the other may not actually exist.

Jim
Was This Post Helpful? 0
  • +
  • -

#12 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 86
  • Joined: 11-November 18

Re: About pointers (being able to access unallocated memory)

Posted 30 January 2019 - 07:27 AM

Idk I saw "Stack is faster than heap" as a point of difference between stack and heap on like two sites. They didn't tell why tho just said that it's preferred. I guess that confused me.

Quote

The stack is faster because the access pattern makes it trivial to allocate and deallocate memory

So itz faster because of the fact that its known compile time..

Quote

The actual values held in memory don't change when you deallocate memory. However those values can be overwritten at any time.

Even after program termination?

Also,

string str = "hahaha";
"hahaha" is an lvalue right? Where does it get stored?

If in stack, then is it possible that when I end the program and had a string that was something like "I'm a ghost" would still remain in the RAM? Spooky.

This post has been edited by Nwb: 30 January 2019 - 07:28 AM

Was This Post Helpful? 0
  • +
  • -

#13 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6717
  • View blog
  • Posts: 22,931
  • Joined: 05-May 12

Re: About pointers (being able to access unallocated memory)

Posted 30 January 2019 - 09:37 AM

Regarding the memory "ghost", it depends on the OS. Older versions of DOS and Windows just left memory alone after a program had terminated. So if a new process starts and gets mapped into the memory that a program had previously used, the new process could see the old stuff.

As for this code:
int * array = new int[10];
int * start = &array[0];
int * end = &array[10];    // 10 is beyond allocated memory

for( ; start < end; ++start)
    *start = 0xbaad;



I still can't find the discussion, but there's several things at play as I recall.

The first issue is with regards to end pointing to section of memory that you don't actually own. The arguments I've against it say that you might as well have a pointer pointing out to la-la land, and that's not valid. (e.g. int * end = 1234;). The arguments for it say that pointers can be set to any value, but what is not legal is to actually access the memory that the pointer is pointing to. (e.g. *end = 1234; or int x = *end; is bad). But what about all those direct memory writes to video memory or into low memory ports? Does that mean you can't use pointers to those locations?

The second issue is with regards to overflow. What happens if the runtime allocates memory right at the end of the pointer range?
char * array = new char[256];
char * start = &array[0];
char * end = &array[256];


In the example above, if you had only a 16-bit pointer, and array is allocated at 0xFF00. So &array[255] will return 0xFFFF. Does that that mean that &array[256] return 0x0000 ? What happens to pointer math when you do end - start ?
Was This Post Helpful? 0
  • +
  • -

#14 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2723
  • View blog
  • Posts: 4,349
  • Joined: 21-June 11

Re: About pointers (being able to access unallocated memory)

Posted 30 January 2019 - 10:21 AM

View PostSkydiver, on 30 January 2019 - 05:37 PM, said:

The first issue is with regards to end pointing to section of memory that you don't actually own. The arguments I've against it say that you might as well have a pointer pointing out to la-la land, and that's not valid. (e.g. int * end = 1234;). The arguments for it say that pointers can be set to any value, but what is not legal is to actually access the memory that the pointer is pointing to.


It's valid to have a pointer that points to one past the end of an array. It is not valid to dereference it, but it's valid for the pointer to exist. That's explicitly allowed by the standard. Having a pointer that points two elements past the end of the array (i.e. &array[11]) would be illegal though.

Relevant quote from the standard (emphasis mine):

Quote

When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i−n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.


The quote is about pointer addition, but it also applies to &array[i] since that's equivalent to array+i by the definition of &.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1