Why do we get a segmentation fault in the below code ?

Question

char getstr(){
    static char s[] = "GATE2016";
    return s;
}
int main(){
    printf("%s", getstr());
    return 0;
}

Although I know I am returning an address using a character return type , and the return type must be char* getstr(); but still if I do like this only then I am getting null on GCC compiler and segmentation fault on another compiler so what is the reason for this .

Answer 1

Here is the assembly code (inside main) for the correct version with "char *"

movl    $0, %eax  
call    getstr
movq    %rax, %rsi
movl    $.LC0, %edi
movl    $0, %eax
call    printf

Here is the assembly code (inside main) when "char *" is replaced with "char"

movl    $0, %eax
call    getstr
movsbl  %al, %eax
movl    %eax, %esi
movl    $.LC0, %edi
movl    $0, %eax
call    printf

As we can see and as mentioned din the question, the change is that, due to the prototype of getstr being char, in the second case, the returned value is truncated to just 8 bits. Now this 8 bits with higher bits padded with 0's or 1's (due to sign extension and x64 calling convention) will be used as an address in the second case and that causes segmentation fault. 

i.e., suppose address of s in first case is 0x 4F A1 23 43, in second case this becomes 0x 00 00 00 43.

Even the above is not a strict guarantee as we are using a char (integer) as an address and there might be alignment issue. 

If we keep it simple, answer is undefined behaviour :)

Comments

Sir , just one confusion in your explanation

 "Now this 8 bits with higher bits padded with 0's will be used as an address in the second case and that causes segmentation fault. "

I am nt getting that how does this 8 bit value gets padded with 0's when passed to the print function ?

---

Padding is actually a wrong way to say, but see this line

  movsbl  %al, %eax

Here, al is an 8 bit register and eax is a 32 bit register. And the instruction is doing sign extension- meaning to all higher bits it puts the sign bit. i.e., for positive number 0 gets filled and for negative number 1 gets filled. This is done due to x64 calling convention that parameters must be passed in so and so registers and would be different where a different calling convention is used. 

One more thing: this extended 32/64 bit value is taken just because "%s" is given which expects an address which is usually 32/64 bits. Had we used %c, only the lower 8 bits would have been taken.