I'm the founder of Coderbyte and also the guy who created this "gets(stdin)" hack.

The comments on this post are correct that is is a form of find-and-replace, so let me explain why I did this really quickly.

Back in the day when I first created the site (around 2012), it only supported JavaScript. There was no way to "read in input" in JavaScript running in the browser, and so there would be a function foo(input) and I used the readline() function from Node.js to call it like foo(readline()). Except I was a kid and didn't know better, so I literally just replaced readline() with the input at run-time. So foo(readline()) became foo(2) or foo("hello") which worked fine for JavaScript.

Around 2013/2014 I added more languages and used third-party service to evaluate code online, but it was very difficult to do stdin/stdout with the services I was using, so I stuck with the same silly find-and-replace for languages like Python, Ruby, and eventually C++, C#, etc.

Fast forward to today, I run the code in my own containers, but never updated the way stdin/stdout works because people have gotten used to the weird hack (some people have even posted in forums explaining how to get around it).

I know it is not best practice and it isn't helpful for someone learning a new language to see hacks like this, but the idea was for new programmers to not worry about reading input at all and just focus on writing the algorithm to solve the problem. One common complaint about coding challenge sites years ago was that new programmers would spend a lot of time just figuring out how to read from stdin or read lines from a file, so I wanted new coders to avoid this problem on Coderbyte.

I'll be updating the entire editor page soon along with the default code and stdin reading for languages. Hopefully then C++ programmers will enjoy using Coderbyte more :)

I am intrigued. So, time to put the investigation goggles on and since I don't have access to the compiler or compilation flags I need to get inventive. Also because nothing about this code makes sense it's not a bad idea question every assumption.

First let's check the actual type of gets. I have a little trick for that:

template <class> struct Name;



int main() { 



    Name<decltype(gets)> n;



  // keep this function call here

  cout << FirstFactorial(gets(stdin));

  return 0;



}

And that looks ... normal:

/tmp/613814454/Main.cpp:16:19: warning: 'gets' is deprecated [-Wdeprecated-declarations]

    Name<decltype(gets)> n;

                  ^

/usr/include/stdio.h:638:37: note: 'gets' has been explicitly marked deprecated here

extern char *gets (char *__s) __wur __attribute_deprecated__;

                                    ^

/usr/include/x86_64-linux-gnu/sys/cdefs.h:254:51: note: expanded from macro '__attribute_deprecated__'

# define __attribute_deprecated__ __attribute__ ((__deprecated__))

                                                  ^

/tmp/613814454/Main.cpp:16:26: error: implicit instantiation of undefined template 'Name<char *(char *)>'

    Name<decltype(gets)> n;

                         ^

/tmp/613814454/Main.cpp:12:25: note: template is declared here

template <class> struct Name;

                        ^

1 warning and 1 error generated.

gets is marked as deprecated and has the signature char *(char *). But then how is FirstFactorial(gets(stdin)); compiling?

Let's try something else:

int main() { 

  Name<decltype(gets(stdin))> n;



  // keep this function call here

  cout << FirstFactorial(gets(stdin));

  return 0;



} 

Which gives us:

/tmp/286775780/Main.cpp:15:21: error: implicit instantiation of undefined template 'Name<int>'

  Name<decltype(8)> n;

                    ^

Finally we are getting something: decltype(8). So the entire gets(stdin) was textually replaced with the input (8).

And the things get weirder. The compiler error continues:

/tmp/596773533/Main.cpp:18:26: error: no matching function for call to 'gets'

  cout << FirstFactorial(gets(stdin));

                         ^~~~

/usr/include/stdio.h:638:14: note: candidate function not viable: no known conversion from 'struct _IO_FILE *' to 'char *' for 1st argument

extern char *gets (char *__s) __wur __attribute_deprecated__;

So now we get the expected error for cout << FirstFactorial(gets(stdin));

I checked for a macro and since #undef gets seems to do nothing it looks like it isn't a macro.

But

std::integral_constant<int, gets(stdin)> n;

It compiles.

But

std::integral_constant<int, gets(stdin)> n;    // OK

std::integral_constant<int, gets(stdin)> n2;   // ERROR                                          wtf??

Doesn't with the expected error at the n2 line.

And again, almost any modification to main makes the line cout << FirstFactorial(gets(stdin)); spit out the expected error.

Moreover the stdin actually seems to be empty.

So I can only conclude and speculate they have a little program that parses the source and tries (poorly) to replace gets(stdin) with the test case input value before actually feeding it into the compiler. If anybody has a better theory or actually knows what they are doing please share!

This is obviously a very bad practice. While researching this I found there is at least a question here (example) about this and because people have no idea that there is a site out there who does this their answer is "don't use gets use ... instead" which is indeed a good advice but only confuses the OP more since any attempt at a valid read from stdin will fail on this site.

TLDR

gets(stdin) is invalid C++. It's a gimmick this particular site uses (for what reasons I cannot figure out). If you want to continue to submit on the site (I am neither endorsing it neither not endorsing it) you have to use this construct that otherwise would not make sense, but be aware that it is brittle. Almost any modifications to main will spit out an error. Outside of this site use normal input reading methods.

I tried the following addition to main in the Coderbyte editor:

std::cout << "gets(stdin)";

Where the mysterious and enigmatic snippet gets(stdin) appears inside a string literal. This shouldn't possibly be transformed by anything, not even the preprocessor, and any C++ programmer should expect this code to print the exact string gets(stdin) to the standard output. And yet we see the following output, when compiled and run on coderbyte:

8

Where the value 8 is taken straight from the convenient 'input' field under the editor.

From this, it's clear that this online editor is performing blind find-and-replace operations on the source code, substitution appearances of gets(stdin) with the user's 'input'. I would personally call this a misuse of the language that's worse than careless preprocessor macros.

In the context of an online coding challenge website, I'm worried by this because it teaches unconventional, non-standard, meaningless, and at least unsafe practices like gets(stdin), and in a manner that can't be repeated on other platforms.

I'm sure it can't be this hard to just use std::cin and just stream input to a program.