Why is this surprising? Do programmers not read books anymore? Almost, any decent C programming book explains that #include reads the specified file and substitutes itself with the content of that file. Any Unix/Linux book explains that /dev/stdin is a special device file that represents the standard input.
Of course, I know how the #include mechanism works, and what the special device files do, so I can anticipate the results of #include </dev/stdin>, but it is unusual enough that I had to write a small test program to see for myself.
I never thought about it in terms of a security problem.
I've surprised some coworkers -- ones who are definitely not inexperienced or just learning -- by e.g. using /dev/stdout as a logfile, or even /dev/pts/x to have multiple logs directly written to separate terminal windows. They all "knew" that devices are files, but never thought about actually trying to use them as such.
No need to be condescending. Three reasons:
1) A sophisticated compiler might read the length of a file before loading it, so that it can allocate a buffer of the right size. Doesn't work with /dev/stdin.
2) Alternatively, it might read the file via mmap(). Doesn't work with /dev/stdin.
3) Furthermore, it might check whether the file is a regular file. If not, it is almost certainly not what the programmer had in mind.
gcc does this. It appears to be why /proc files don't work. gcc sees that stat calls it a 'regular file' and 0 bytes long, and actually performs a read() syscall with a length of 0.
> 3) Furthermore, it might check whether the file is a regular file. If not, it is almost certainly not what the programmer had in mind.
gcc probably does this. (It would explain why /dev/stdin works)