-1
#include <stdio.h>

int main(void)
{
    int *ptr;
    printf("%p", ptr); // Error: uninitialized local variable 'ptr' used
                       // Output is "0"
}

I'm reading C-FAQ about null pointer. And it says that uninitialized pointer might point to anywhere. Does that mean it points to random location in memory? Also if this statement is true, why does error occur if i try printf("%p",ptr)? Since uninitialized pointer ptr points to some random location, it seems that it must print out this random location!

Jin
  • 1,902
  • 3
  • 15
  • 26
  • 5
    It points to an indeterminate location — you can't readily predict where it will point, but it is unlikely to random in any strict meaning of the term. What error does occur when you use `printf("%p", ptr);`? You could be being told that `%p` expects a `void *` and you are passing a `char *` (not the same thing). You might not be seeing any output because you don't have a newline at the end of the printing. You might be suffering from something else. You've not shown an MCVE ([MCVE]) or the error message you get, so we can't help you. – Jonathan Leffler Aug 10 '16 at 02:51
  • Why wouldn't it just point to null(0x0)? – Hedron Aug 10 '16 at 02:56
  • 1
    "And it says that uninitialized pointer **might** point to anywhere" is true. "Since uninitialized pointer ptr points to some random location" is not necessarily true. It may also have a trap value that when referenced kills the code. It may have an illegal value the makes no sense to interpret as a pointer. It is not _initialized_. It is UB -undefined behavior. – chux - Reinstate Monica Aug 10 '16 at 02:56
  • @hedron It can depending on where/how the pointer is declared. Non-auto variables (e.g. globals) are indeed initialised to zero. But I guess you are asking why it can't always be initialised to 0 - the answer is because C is a minimialist language. It costs something (e.g. cpu time) to do implicit initialisation. So why pay that cost when correctly written code will do an explicit init anyway? – kaylum Aug 10 '16 at 03:00
  • Works for me (linux x86_64/gcc 4.4.7), and prints out 0, using printf with `%p` and casting to `(void *)` gives me the output "(nil)". So this is obviously your compiler. I don't think this should be UB (we aren't dereferencing the pointer then again the output is likely to be implementation defined .... which is slightly different from UB). – dave Aug 10 '16 at 03:10
  • 1
    @dave it is UB according to the C Standard (using an uninitialized variable) – M.M Aug 10 '16 at 03:13
  • @M.M It is not necessarily UB, the value is indeterminate. It could either be a garbage value (unspecified behavior) or a trap representation (undefined behavior). – Lundin Aug 10 '16 at 06:32
  • @Lundin See C11 6.3.2.1/2 and http://stackoverflow.com/questions/25074180/ – M.M Aug 10 '16 at 06:36
  • @Lundin: It *is* necessarily undefined behavior. – Keith Thompson Aug 10 '16 at 16:00
  • This is yet another dead horse debate that's been discussed on SO many times before. Yeah in case you just print the uninitialized pointer itself then it is UB because it could have been declared as `register`. That's a special case. Otherwise, if the address of the variable was taken, it is only UB in case of trap representations. – Lundin Aug 11 '16 at 06:12

1 Answers1

2

The contents of an unitialized auto variable (pointer type or otherwise) are indeterminate; in practice, it's whatever was last written to that memory location. The odds that this random bit pattern corresponds to a valid address1 in your program are pretty low; it may even be a trap representation (a bit pattern that does not correspond to a legal value for the type).

Attempting to dereference an invalid pointer value results in undefined behavior; any result is possible. Your code may crash outright, it may run with no apparent issues, it may leave your system in a bad state.

  1. That is, the address of an object or function defined in your program, or a dynamic object allocated with malloc or similar.

John Bode
  • 119,563
  • 19
  • 122
  • 198
  • In fact, dereferencing an uninitialized pointer *always* has undefined behavior, even if it happens by coincidence to contain the address of some valid object. The standard explicitly says so; see [N1570](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf) 6.3.2.1p2 (thanks to M.M for the citation). – Keith Thompson Aug 10 '16 at 16:02
  • You might want to consider revising this answer, the variable is an automatic one, having never had its address taken, it is UB as in **UB**, even if you do null check it... – Antti Haapala -- Слава Україні Nov 20 '19 at 14:34