Original text:
Given a float as input_float: <del> If input_float is not a IEEE 754 double precision number, fail serialisation. </del>  Let output be an empty string.

Reviewer comments:
Is this PR meant to include ?
Yeah, oops. Need more coffee.
Try now.
Otherwise, looks alright to me.
The current definition of sh-float is surprisingly hard to serialize correctly, the best C-code I could come up with is: int serializeshfloat(char buf[18], double d) { int p = 0, l, dig; buf[0] = ''; buf[1] = '\0'; if (isnan(d)) return (-1); if (fabs(d) >= 99999999999999.95) return (-1); if (d = 99999999999999.95) return (-1); if (d < 0) { buf[p++] = '-'; d = -d; } p += snprintf(buf + p, 18 - p, "%-16f", d); while (buf[p-1] == ' ') p -= 1; buf[p] = '\0'; return (p); }
+1 from me, our primary focus should be on data types that will have good interop. That level of precision isn't necessary for any current use of HTTP headers I'm aware of, off the top of my head.
Proposal: Call these decimal. Allow a maximum of 9 digits on the left of the decimal place and 6 after. This matches the definition for int and allows storing this in the same sized slot with a or conversion factor.
ABNF gets much simpler.
NAME That would probably curtail the range too much. I think it is desirable to be able to move posix time_t timestamps in these.
If this really is an integer with fixed point semantics, why do we need it at all?
Because it's easier than making people specify "divide the number by a million to get its real value"? That said, I agree that 9 digits to the left of the point is probably not enough, so a floating point representation is more useful. This is the ABNF equivalent of NAME C code, yeah?: That easily gets us a current 32-bit time_t plus microseconds, and a whole range of other values besides.
Why do the arguments about size of integers not also apply here? is 64-bit on my system, which doesn't fit in the sh-integer definition either.
The current time is ish. You don't need to prefix it with 30 bits worth of zeroes.
I've read the IETF105 minutes, and thought about the fixed-point discussion. All the uses for "decimal number with fractional part" I can think of\ would reasonably served by at least 10 digits to the left\ and at least 3 to the right of the point. So I would support any fixed- or floating-point representation that supports that range of values. \ that's all that matters, right? \ a ten-decimal-digit time_t gives us until November 20, 2286
Using the max-six-decimal definition, and allowing 15 digits with no period or decimals, this C-code will do the job: static char * sh_float(double d) { static char buf[40]; int n; if (fabs(d) < 1000000000) { n = snprintf(buf, sizeof(buf), "%f", d); while (buf[--n] == '0') buf[n] = '\0'; if (buf[n] == '.') buf[n] = '\0'; } else { n = snprintf(buf, sizeof(buf), "%.15g", d); } return (buf); }
Sorry, wrong button.
If I take , then I can almost represent that in a JS float in the most horrific way imaginable: But that doesn't quite fit. 69999999999999999 doesn't fit into a double. If you want to remember the number of additional decimal places so that you don't lose any precision on those trailing decimal places (things like 0.3 are surprisingly tricky to re-encode), you are left with supplementary values. Can someone make a better case for any more than 10^10 values here? I couldn't see a good one. You can fit a 32-bit value in that. If you really think that time_t is valuable, which I'm totally not convinced of, then fewer steps might be acceptable. I can pack this:
PR updated. Any further comments, or ready to merge?

Revised text:
Given a float as input_float:  <ins> If input_float's fractional part has more than six digits of precision, fail serialisation. If the number of digits of precision in input_float's fractional part plus those in its integer part add to more than fifteen digits, fail serialisation. </ins> Let output be an empty string.