Q:

what should printf("%.17g\n", .1) print?

I've often used the command-line program "printf"
to test/predict what the C stdio library function will do.
But I've recently found that doesn't work (any more?)--
at least on a recent linux/ubuntu release,
the command-line printf (both the bash builtin and /usr/bin/printf)
sometimes gives different results from the C function.
That means if I want to see what the C function will do,
I have to run some other program that actually calls the C function, such as (apparently)
python, perl, gnuplot, or an actual C program.
Here's a demonstration, on linux:
bash$ uname -srvmpio
    Linux 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
bash$ bash --version
    GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
    Copyright (C) 2013 Free Software Foundation, Inc.
bash$ type printf
    printf is a shell builtin
bash$ printf "%.17g\n" .1
    0.1
bash$ /usr/bin/printf "%.17g\n" .1
    0.1
bash$ python -c 'print "%.17g" % .1'
    0.10000000000000001
bash$ perl -e 'printf("%.17g\n", .1);'
    0.10000000000000001
bash$ gnuplot -e 'print sprintf("%.17g", .1)'
    0.10000000000000001
bash$ echo -e '#include <stdio.h>\nint main(){printf("%.17g\\n",.1);}' | gcc -xc - -o /tmp/printf_.1 && /tmp/printf_.1
    0.10000000000000001

On some other platforms, e.g. an up-to-date macbook, they all give "0.10000000000000001"
(which I've always thought was the right answer):
bash$ uname -srvmp
    Darwin 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64 i386
bash$ bash --version
    GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)
bash$ type printf
    printf is a shell builtin
bash$ printf "%.17g\n" .1
    0.10000000000000001
bash$ /usr/bin/printf "%.17g\n" .1
    0.10000000000000001

I'm of course surprised and disappointed that the above commands don't all give exactly the same output within any particular platform.
My question is: is there a single correct answer, according to some official spec, and, in any case, should a bug report be filed?
Some background facts:
.1 in C denotes the IEEE double-precision floating-point number
whose value is exactly, mathematically:
x  = 0.1000000000000000055511151231257827021181583404541015625

and the adjacent representable values are:
x- = 0.09999999999999999167332731531132594682276248931884765625
x+ = 0.10000000000000001942890293094023945741355419158935546875

Therefore both string representations "0.10000000000000001" and "0.1" are non-lossy,
in the sense that they are both closer to x than to any other double-precision value;
that is, any reasonable string-to-double conversion function will produce
x when given either string.  So both answers are equally good in this sense.
However, 0.10000000000000001 is closer to x than 0.1 is.
I've always thought that implies "0.10000000000000001" is the right answer,
but now I'm not sure; maybe it's an implementation-dependent detail?
For an explanation of why 17 is the right number of digits to be using in any case, see
the documentation for numeric_limits::max_digits10:
http://en.cppreference.com/w/cpp/types/numeric_limits/max_digits10
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2005.pdf

A:

Following is about C in general and may/may not apply to bash or posix specifications.
printf("  %.17f\n", .1) is expected to print at least  DBL_DECIMAL_DIG correct significant digits. DBL_DECIMAL_DIG is the precision guaranteed for a double to decimal textual representation back to double and get the same result.  To do this, at least 10 and commonly 17 significant digits are correct.  This is OP's situation which OP certainly understands well.
//0.09999999999999999167332731531132594682276248931884765625
//0.1000000000000000055511151231257827021181583404541015625
//0.10000000000000001942890293094023945741355419158935546875
//  12345678901234567
  0.10000000000000001  // DBL_DECIMAL_DIG is commonly 17

The problem is, printf() is not required to do any of this very correctly.  So the quality of printf() would be considered marginally acceptable if it printed either of the two below as 0.1 could round-trip via either text successfully.
//  12345678901234567
  0.10000000000000001 
  0.10000000000000000

The accuracy of the floating-point operations (+, -, *, /) and of the library functions in <math.h> and <complex.h> that return floating-point results is implementation defined, as is the accuracy of the conversion between floating-point internal representations and string representations performed by the library functions in <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state that the accuracy is unknown.  C11dr §5.2.4.2.2 6

[Edit]
A double can have various precision, base, range details.  For simplification, this discussion is about a sample value than it not 0.1, but 0.10000000000000000555...
The comment of @user694733 is useful, yet it is under "Recommended practice" which uses "should be a exact ...".  Although it does not specify the hoped for "0.10000000000000001" for printf("%.17f", .1).  It, along with the above helps answers OP's question: "What should print?",  "0.10000000000000001" should be printed.  But that accuracy is implementation defined by C.
For a C implementation that claims compliance to EEE floating point, I am confident that a result of "0.10000000000000001" or "0.10000000000000000" is required, but that is beyond a C question and into a IEEE 754-xxxx one.  My reading of IEEE floating point Character representation allows a conforming implementation that latitude as only round-tripping a double (actually binary64) --> text --> double is required.  This takes at least 15 significant digits and may take as many as 17.  What those digits are past the 15th is not specified other than the conversion of the text to double returns the starting double.

Deeper.  For IEEE 754, a value of 0.100000000000000005551115123... could "wrongly" print as anything up to "0.10000000000000001249000902..." and still correctly round-trip.  
//  12345678901234567
//0.1000000000000000055511151231257827021181583404541015625
//0.10000000000000001249000902...  half way
//0.10000000000000001942890293094023945741355419158935546875

Note: IEEE allows converting text to a double to ignore significant digits beyond a certain amount (20 for double).  

Short IEEE answer: output should lie within the range of [C I] below when printing X to various precisions.
    12345678901234567
A 0.099999999999999991673327315... preceding X
B 0.099999999999999998612221219... half way
C 0.099999999999999998613          half way rounded to 20 sig digits toward x
D 0.099999999999999999             "%.17e" candidate
E 0.10000000000000000              "%.17e", "%.17f" candidate 
X 0.100000000000000005551115123... 
G 0.10000000000000001              "%.17e", "%.17f" candidate
H 0.10000000000000001249           half way rounded to 20 sig digits toward x 
I 0.100000000000000012490009027... half way
J 0.100000000000000019428902930... following X

