Actually, make that 10 separate symbols, as the 5 nan symbols that appear in the output of BrowserUk's qnan.c, under some circumstances, will be suffixed with '0' ('00' in the case of 1.#IND).I wonder why so many symbols are needed ?
The suffixing of zeros to the symbols is just an artifact of using "%f" printf format, which implicitly is equivalent to "%.6f" and therefore requires that the fractional part be padded with trailing zeros to 6 places.
If you adjust the template, you can see this. (The printf from your code above + output):
printf("%f %f\n", inf / inf, (inf / inf)); // 1.#IND00 1.
+#IND00
printf("%.4f %.4f\n", inf / inf, (inf / inf)); // 1.#IND 1.#I
+ND
printf("%.10f %.10f\n", inf / inf, (inf / inf)); // 1.#IND000000
+ 1.#IND000000
I've found %g more useful: printf("%g %g\n", inf / inf, (inf / inf)); // 1.#IND 1.#IN
+D
It's also interesting that,of my Microsoft compilers (6.0, 7.0 and 8.0), none of them produce the same output as BrowserUk's 9.0 compiler.
The changes are (roughly) in line with the timing of the compiler releases relative to the requirements of the various ANSI C standards C89/C90/C99/C11; and as affected by the updates to the IEEE754 (1987) standard and its revision in 2004. (Roughly:)
For that program, my 8.0 MS compiler outputs: 1.#IND00 1.#IND00 but my gcc4.5.2 produces: 1.#IND00 1.#QNAN0 Which one is doing it correctly ?
You'll hate this answer. Effectively, they both are!.
The problem is, the computer scientists and the mathematicians can't agree on a single Function definition with respect to FP math.
The problem is twofold:
 FP math isn't like real math (Real in the mathematical sense).
Eg. FP is not always associative: print +( 10.0**20 + 1 )  10.0**20;;
0
print +( 10.0**20  10.0**20 ) + 1;;
1
 Mathematicians have conventions for the results of some operations that don't quite work arithmetically.
Eg. infinity**0 == 1!
These allow their operations on the continuous Real domain to avoid singularity points
You pays your money and makes your choice.
What operations will result in a signalling nan ?
From what I've been able to discover, none of them! (At least as far as MSC v9 is concerned.)
The problem here is that the IEEE754 allows for traps, but doesn't require them. See Signaling NaNs
My take on what I see coming out of my attempts to produce NaNs with MSC(v9), is that they settled on using 1.#IND as the result of any math operation that is (for want of a better phrase) 'not well defined'. eg. sqrt( 1 ), 0/0; fmod( 1, 0 ) etc.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks  Silence betokens consent  Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
