Reading from stdout using file pointer and decrementing it

I am trying to analyze the following piece of code:

FILE* out=stdout;
	
	printf("\nEnter value: \n");
	
	out=out-1;
	
	char ch;
	
	while(ch!=EOF){
		ch=fgetc(out);
		printf("\nValue printed: %c\n",ch);
	}
	
	fclose(out);

The following output is observed when I run this code:

Enter value:
IWantToC

Value printed: I

Value printed: W

Value printed: a

Value printed: n

Value printed: t

Value printed: T

Value printed: o

Value printed: C

Value printed:

I understand that fgetc is fetching the value from out(which is pointing to stdout) one character at a time and printing it till it reaches the file end.

What is out=out-1 doing here? If out was originally pointing to the beginning of the stdout file, then shouldn't it be printing chars from "Enter value:" as well. Or if it is pointing to the end of the stdout file, then shouldn't it be printing only one character from the end? Also, why is it expecting user input in the first place? Is it because of getc?

Sorry for the many questions. If someone clarifies those doubts, it will be very helpful for me to understand C. I have seen related questions here but haven't found any particularly addressing my queries.

It's undefined behavior.

On some systems (i.e. libc variant), the three standard streams are defined in an array (e.g):

FILE __stdlist[3];

#define stdin  (&__stdlist[0])
#define stdout (&__stdlist[1])
#define stderr (&__stdlist[2])

That's why it seems to work. Because with:

FILE *out = stdout;

out = out - 1;

Now, out is stdin.

But, this is just one libc. It can totally different with other systems. There is no requirement [or guarantee] that the FILE descriptors are in contiguous memory.

If you had (e.g.):

FILE *stderr;
int x;
FILE *stdout;
int y;
FILE *stdin;
int z;

Then, the "trick" would not work.

Do not use this.

Side note: Change char ch; into int ch;. Otherwise, if you got a legitimate 0xFF on the input, it would erroneously be interpreted as -1 (i.e. EOF).

UPDATE:
>On a system where the standard streams are defined in an array, as shown in your first example, the behavior of the OP's code is perfectly well defined, and should be expected to work reliably, so an unqualified "It's undefined behavior" is incorrect. However, it is unspecified whether the behavior is defined, and a program that relies on that behavior does not conform strictly to the language spec. –
John Bollinger

So, if I said unspecified, things would be okay? How would one reliably detect this?

Even on glibc [which does this--I checked], how does one know unless we do #ifdef __GLIBC__ or some such.

Otherwise, I think we must assume stdout points to a single instance. If we do:

int val;
int *ptr = &val;
ptr = ptr - 1;

[Without consulting the spec] I think that's UB.

We could just as easily have:

FILE *__stdlist[3];

#define stdin  (__stdlist[0])
#define stdout (__stdlist[1])
#define stderr (__stdlist[2])

And, the array elements are initialized from (e.g.) malloc + some setup.

And, again it won't work.

UPDATE #2:
>please correct me if I am wrong in understanding your answer. So, when I write out=out-1, it goes into stdin and waits for user input.

For terminology, I'm not sure I would say "goes into stdin". I'd say it "points to stdin" or "is set to the value of stdin".

>After I give the input, it reads from the same stdin input and prints out the characters one by one. Is that correct? –
NeuronB

At that point, using the "trick" [which, you can't use], we have out pointing to the same address as stdin points to. So, the clean way to do this is:

FILE *out = stdin;

After that, this is just a simple loop that:

1. reads one char from the out stream [which is now stdin]
2. if the char read is EOF, the loop is ended.
3. prints it to the display (i.e. stdout).