1
#include <stdio.h>

int main(){
 char *a;
 scanf("%s", a);
 printf("%s\n", a); 
 return 0;
}

Above code compiles and runs successfully for the input hello.

My question is how does this even run without me having allocated anything on the stack? is it basically overwriting memory?

What is a even pointing to? a random location?

  • It's undefined behavior. Just don't do it. – klutt Apr 11 '20 at 16:08
  • C does not care. It is undefined behavior. So char* a may have some random value in it. and may work one day and fail the next. – OldProgrammer Apr 11 '20 at 16:08
  • The only thing `char *a;` reserves is space for the pointer `a` itself - nothing else. – Mat Apr 11 '20 at 16:09
  • 2
    Does this answer your question? [Taking string input in char pointer](https://stackoverflow.com/questions/14707427/taking-string-input-in-char-pointer) – Dickens A S Apr 11 '20 at 16:14

1 Answers1

1

Your code has undefined behavior:

From ISO/IEC 9899:201x N1570 §3.4.3

1. undefined behavior

Behavior, upon use of a non portable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements.

2. NOTE

Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

From https://devdocs.io/c/language/behavior

There are no restrictions on the behavior of the program ... Compilers are not required to diagnose undefined behavior (although many simple situations are diagnosed), and the compiled program is not required to do anything meaningful.

...

Because correct C programs are free of undefined behavior, compilers may produce unexpected results when a program that actually has UB is compiled with optimization enabled.

I ran this code in my compiler (gcc version 8.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)) and it segfaulted.

Community
  • 1
  • 1
anastaciu
  • 23,467
  • 7
  • 28
  • 53
  • It is not true that “undefined behavior,” as the term is used in the C standard, means that anything can happen, and the reference you cite is wrong to say there are no restrictions on the behavior of the program. When the C standard says something is “undefined,” that only means **the C standard** does not impose any restrictions. It does not, and cannot, nullify any other restrictions or specifications. Implementations and systems often, even usually, provide their own definitions of some things not covered by the C standard. – Eric Postpischil Apr 11 '20 at 16:22
  • So a program with behavior not defined by the C standard is still governed by rules for the linker, limitations imposed by the operating system and more—it is not true that anything can happen because things other than the C standard prevent it. You may understand this, but new students often do not, and telling them this false statement interferes with their learning how all the parts of a system operate and contribute. – Eric Postpischil Apr 11 '20 at 16:24
  • @EricPostpischil, I removed the remark. I'll look at the standard to improve my citations. – anastaciu Apr 11 '20 at 16:26