However, I am a bit hesitant to award the bounty on either answer. Dennis' answer relies on GCC, UTF-8 compatibility, the interpreter /lib64/ld-linux-x86-64.so.2
and Unix.
I think it's a bit strange that you hold our answers to higher standards than your own. Yes, my answer requires at the very least GCC, an x86_64 CPU/OS, and an interpreter with path /lib64/ld-linux-x86-64.so.2
. That sounds like a lot, but it means that it will work on pretty much every Linux machine you encounter in the wild. UTF-8 support is not required; my answer only uses ASCII characters.
Meanwhile, your main(){puts('s');}
answer actually produces zero bytes of output. Yes, running the program in my terminal displays Segmentation fault
, but that output is caused by the shell, not your program. You can verify this by piping STDOUT and STDERR to a byte counter.
./quine |& wc -c
0
Now, my terminal uses Bash in interactive mode. Any other shell and any other way of invocation may produce different output.
Segmentation fault # Bash, interactive
bash: line 1: 8176 Segmentation fault ./quine # Bash, non-interactive
[1] 9004 segmentation fault ./quine # Zsh, interactive
# Zsh, non-interactive
Memory fault # Ksh, interactive
ksh: line 1: 9417: Memory fault # Ksh, non-interactive
So your program may display the proper output on the screen, but this requires not only Linux, but a specific parent shell. In some cases, the output even depends on the PID.
Then again, Anders' answer relies on default filenames (which qualifies as using the filename to store data) and non-standard <err.h>
.
Including err.h is exactly as necessary as including stdio.h. If one has to include err.h to use warn
or err
in your opinion, one would have to include stdio.h to use puts
as well, and your answer uses puts
.
I'm not sure if online interpreters actually count as different implementations of the language, so the validity of the Ideone-only solution is debatable. However, gcc's default name for output files is a.out
, so I see no reason whatsoever why the longer of the two solutions would be invalid.
Which answer should I give my bounty to?
Well, that's ultimately up to you. You said +100 to anyone who can find a shorter solution in C than my three 19-byte solutions, which can be interpreted in a number of ways, namely:
- First answer that beats your score.
- Shortest answer that beats your score and was posted during the bounty period.
- All future answers that beat your score.
Only you know what you meant. It probably wasn't the last one, but even if it was, SE won't allow you to offer a second +100 bounty on the same question. That leaves the first two options.
If I were you, I'd award the bounty to @AndersKaseorg's answer. Both his and my answer are valid to the best of my knowledge, but his answer is shorter, and shorter is better.