Return to Answer

Again, you should check that you got some data read. Note that with "%s", scanf() first skips any white space (blanks, tabs, newlines) and then reads one word — a sequence of non-blanks. You've not limited the size of the input. If the user said 10 characters but typed 20 characters before the newline or first blank or tab, you'd have problems. If the array size was fixed at, say, 1024 bytes in total, you could use "%1023s" to limit the input to 1023 non-blanks and the terminating null byte. With a variable length array, it's harder. (This is a common oversight in programs, even those by people with lots of experience.)

Again, you should check that you got some data read. Note that with "%s", scanf() first skips any white space (blanks, tabs, newlines) and then reads one word — a sequence of non-blanks. You've not limited the size of the input. If the user said 10 characters but typed 20 characters before the newline or first blank or tab, you'd have problems. If the array size was fixed at, say, 1024 bytes in total, you could use "%1023s" to limit the input to 1023 non-blanks and the terminating null byte. With a variable length array, it's harder. (This is a common oversight in programs, even those by people with lots of experience.)

You should always specify the return type of every function, including main(). You're using either C99 or C11, so you are required to specify the return type. (The oldest version of the standard, C90, wasn't quite so fussy.). Further, the return type of main() should be int, though if you work with Microsoft compilers, they allow void too. The standard is quite clear; int is expected. It's often a good idea to say explicitly 'no command line arguments' by writing int main(void), but in practice, int main() also works fine almost all the time. (You have to be doing weird things for it to matter.)

You also ask about using gets(). You should never use gets()! There is no safe way to use gets() because you cannot prevent buffer overflows when you do. You should use fgets() by default, or getline() if you work on a POSIX-based system. Note that both those retain the newline, whereas gets() removes it. One good idiom for removing a trailing newline from fgets(buffer, sizeof(buffer), stdin) is buffer[strcspn(buffer, "\n")] = '0円'; which works correctly whether there's a newline in the buffer or not. With getline(), it tells you how long the string is so you can use that to remove the newline (though there's an outside chance that the file doesn't end with a newline, so the last line read won't have a newline — which is irksome).

You should always specify the return type of every function, including main(). You're using either C99 or C11, so you are required to specify the return type. (The oldest version of the standard, C90, wasn't quite so fussy.). Further, the return type of main() should be int, though if you work with Microsoft compilers, they allow void too. The standard is quite clear; int is expected. It's often a good idea to say explicitly 'no command line arguments' by writing int main(void), but in practice, int main() also works fine almost all the time. (You have to be doing weird things for it to matter.)

You also ask about using gets(). You should never use gets()! There is no safe way to use gets() because you cannot prevent buffer overflows when you do. You should use fgets() by default, or getline() if you work on a POSIX-based system. Note that both those retain the newline, whereas gets() removes it. One good idiom for removing a trailing newline from fgets(buffer, sizeof(buffer), stdin) is buffer[strcspn(buffer, "\n")] = '0円'; which works correctly whether there's a newline in the buffer or not. With getline(), it tells you how long the string is so you can use that to remove the newline (though there's an outside chance that the file doesn't end with a newline, so the last line read won't have a newline — which is irksome).

One other problem, pointed out by NowIGetToLearnWhatAHeadIs in comments is that your decoding steps are not an exact reverse of your encoding steps.

One other problem, pointed out by NowIGetToLearnWhatAHeadIs in comments is that your decoding steps are not an exact reverse of your encoding steps.