I've learned about wild pointers and how to avoid them. I've heard that they point to a random value in memory and I was wondering if they actually have a random and completely irrelevant value or if they point to a certain value that's probably implementation dependent. Which is it?
Asked
Active
Viewed 61 times
0
-
5They're uninitialized, so they could point anywhere. It might be to unmapped memory, so you get a segmentation violation, or it could point to something important and assigning through it will corrupt that data. – Barmar Feb 22 '22 at 21:44
-
...or, on a system without virtual memory, it could point to some unused memory and nothing bad happens at all. But you don't know what you're gonna get. And it might not be the same thing every time. – ikegami Feb 22 '22 at 21:46
-
3"Random" is potentially misleading. Wild (uninitialized) pointers point to an indeterminate location, and bad things are likely to happen if you dereference them, especially if you try writing through them. But the values are not random in the sense of uniformly distributed across the address space of the process. – Jonathan Leffler Feb 22 '22 at 21:46
-
It depends a little bit on what you mean by "wild pointer". A pointer variable that's local and has never been initialized is "random" in one way. A pointer variable that used to be valid but now isn't — either because it pointed to a local variable in a function whose execution has finished, or because it pointed to memory obtained from `malloc` which has since been freed — is "wild" in a different way. – Steve Summit Feb 22 '22 at 23:16
-
For uninitialized variables, including uninitialized pointer variables, it's hard to come up with a truly descriptive word. They're not really "random". I like to say that *uninitialized local variables never start out holding what you expect*. If you expect them to be random, you'll find that (at least on any given day) they're utterly repeatable and predictable, and often 0 or NULL. But if you expect them to be predictable (and especially, god help you, if you write code that depends on it), then by jingo, you'll find that they're quite random. – Steve Summit Feb 22 '22 at 23:17
-
See also [this answer](https://stackoverflow.com/questions/37087286/c-program-crashes-when-adding-an-extra-int/37087465#37087465) to a partially-related question. – Steve Summit Feb 22 '22 at 23:17
2 Answers
1
These dangling pointers are not random in the "mathematical" sense. They point to an implementation dependent location (based on hardware arch, runtime sequence, etc), that your program isn't supposed to have access to & the content of the pointed location is undefined from your program's point of view. The operating system is free to re-allocate & write whatever whenever so your pointer to that memory is deemed "random" in its value.
eliangius
- 326
- 3
- 10
0
The value isn't random in the sense that it has an even probability of being any value. The value is merely unknown.
It could point to memory being used by something else in your program. Writing to this memory could cause other parts of your program to malfunction, or it might trigger a protection fault.
It could point to unused memory. Reading from this memory could trigger a protection fault. Writing to this memory might work fine, or it might trigger a protection fault.
You don't know which of these outcomes you're going to get.[1] And it's not always going to be the same. So there's no practical purpose to using an uninitalized pointer.
- The hardware limits some, but not all, options.
ikegami
- 367,544
- 15
- 269
- 518
-
It wouldn't surprise me that you could get different values from inspecting the same uninitialized var twice in the same program, even if the value of the variable isn't changed in between. But I can't say that's actually the case. – ikegami Feb 22 '22 at 22:00
-
1That's the concept that uninitialized variables are "wobbly", meaning they don't necessarily retain the value read the first time for any subsequent attempt. "Interesting" times. – Deduplicator Feb 22 '22 at 22:03