-2
#include <stdio.h>

int main(void){
  int n;
  int a[5];
  int *p;

  a[2] = 1024;
  p = &n;

 /* adding any of these lines makes code to print "a[2] = 98" at output */
  p[5] = 98; //OR *(p + 5) = 98;

  printf("a[2] = %d\n", a[2]); //Prints a[2] = 98
  return (0);
}

I don't understand why this C code magically prints "a[2] = 98". Though, this is what I want but I want to understand it.

pasignature
  • 577
  • 1
  • 6
  • 13
  • 4
    This is undefined behavior, so anything can happen. What probably happens is that it just calculates where `p[5]` would be and that happens to be the memory location of `a[2]`. – Blaze Feb 25 '20 at 08:44
  • I want to understand this "undefined behavior". – pasignature Feb 25 '20 at 08:45
  • 1
    Please see [Should I try to explain undefined behaviour?](https://meta.stackoverflow.com/questions/271372/should-i-try-to-explain-undefined-behaviour) – Weather Vane Feb 25 '20 at 08:48
  • 2
    To understand what the compiler did, you need to look at (and interpret) the assembler output. Mind you... the compiler can output different assembler for the same code with different options, with different computer load, with different phase of the moon, ... – pmg Feb 25 '20 at 08:48
  • Also see [Undefined, unspecified and implementation-defined behavior](https://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior). – Weather Vane Feb 25 '20 at 08:49
  • 2
    `p` is not pointing to an array, so any indexing except `p[0]` is undefined. It looks as though the code is expecting a particular arrangement of the variables. – Weather Vane Feb 25 '20 at 08:50
  • 2
    writing `p[5] = ...` makes no sense. you are just playing dangerously with your address space. – Landstalker Feb 25 '20 at 09:09
  • This is one thing I really really dont like on SO. closing a question just bcus you don't know the answer to it is rude and defeating the purpose of SO. user3386109 closed this question as duplicates WHEREAS this link https://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior has NOT answered the question.....they are NOT the same question in the first place so they can't have same answer. If you can't answer a question why not leave it for others who can to help me out? – pasignature Feb 25 '20 at 09:33

1 Answers1

0

If you intend a specific memory layout, don't do it on the base of guesswork concerning the compiler's work, be explicit by using struct for cases like this:

struct {
  int n;
  int a[5];
  int *p;
} vars;

But you should also look up the documentation of the compiler how to force a certain alignment, for instance packed structures.

The memory layout of local variables cannot be consistently deduced from declaration order, it is undefined. And that's why your code is sayd to show undefined behaviour.

Wolf
  • 9,679
  • 7
  • 62
  • 108
  • Woh woh woh!!!......take it easy Wolf. I'm more confused NOW...I'm just learning C I don't know how to use struct yet. I just want to know exactly what happened in the code in my question. – pasignature Feb 25 '20 at 09:08
  • @pasignature maybe you just made a typo and originally wished to assign the pointer `p` to an address of `a`, for instance `&a[0]` which has the same value as `a` (arrays are assignment compatible to pointers), so `p=a` would be well-defined. (by itself) – Wolf Feb 25 '20 at 09:14
  • 1
    @Wolf but `a[5] = 98` is out of range too. – Weather Vane Feb 25 '20 at 09:16
  • @WeatherVane absolutely, but a[5] is not accessed in above code. If the code would be corrected in only this one point, `p=a`, you of course would be right. – Wolf Feb 25 '20 at 09:18
  • @Wolf, my comment was because you said OP might have made a typo, but `p[5]` for `a[5]` is still undefined. – Weather Vane Feb 25 '20 at 09:28
  • 1
    @WeatherVane indeed it looks like ***a couple of "typos"***. Maybe I've better asked for the intention of the code. Interestingly some people code to see what happens instead of following some well-defined goal ... – Wolf Feb 25 '20 at 09:31