Which answer should I give my bounty to?

I started a bounty on this question because I didn't think it could get beaten. The next day it was beaten by Dennis. I was sure this would win, but then it was beaten again.

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.

Then again, Anders' answer relies on default filenames (which qualifies as using the filename to store data) and non-standard <err.h>.

Additionally, neither answer is a full program. I was under the impression that the general concensus for quines was that they should be full programs. In this particular challenge, the output is based off the length of the source code.

Anders' provided source code was f(){warn(0);}, with the output being the same length. But this is clearly not a full program - main(){f();} is required, adding 12 bytes and therefore invalidating the output. Dennis' does the same thing.

Are either suitable for the bounty, or even valid quines?

• you know you wouldn't have been able to give yourself the bounty, right? – Destructible Lemon May 27 '17 at 1:07
• @DestructibleLemon Of course... I just don't want to award a bounty to an invalid answer. – MD XF May 27 '17 at 1:07
• I was under the impression that the general consensus for quines was that they should be full programs. The very first paragraph of the challenge spec says you should write a program or function which takes no input and prints or returns a string with the same number of bytes as the program itself. (emphasis mine) – Dennis May 27 '17 at 1:15
• @Dennis prints ... a string with the same number of bytes as the program itself. Not the function itself, the program itself. (I think.) – MD XF May 27 '17 at 1:16
• On PPCG, program means either full program or function. (source) – Dennis May 27 '17 at 1:17
• @Dennis Oh huh. Thanks for the link. – MD XF May 27 '17 at 1:18

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:

• Shortest answer that beats your score and was posted during the bounty period.

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.

• Plus, you don't need the rep... – caird coinheringaahing May 27 '17 at 7:46
• The bounty should be awarded to whichever answer deserves it. Rep has nothing to do with it. – Dennis May 27 '17 at 7:50
• @Ilikemydog No one needs rep. Rep is just there to show who's more trustworthy/knowledgeable in the community – Beta Decay May 27 '17 at 10:27

I think the a.out-based answer is the least controversial one here. Note that the output filename is a property of the compiler, and on UNIX cc, isn't a function of the input filename; it's always a.out. Most Linux/UNIX C compilers emulate UNIX cc in this regard, meaning that an assumption that the output filename is a.out is highly portable. Also, <err.h> isn't required for it to work (you're confusing header files and libraries); what's actually required is a library containing the warn function (which my manual lists as a "nonstandard BSD extension" which is, in addition to being present in BSD, also present in GNU). So the answer has a high chance of working on most typical consumer BSD-based or Linux-based systems.