CC @robpike @martisch

I don't believe there is a clean way to fix this, and I'm not sure but I think that C's scanf, which is the unfortunate predecessor of this unfortunate facility in Go, offers no solution either.

Absent evidence otherwise, I would close this issue as "unfortunate". Scanf and friends are not good general-purpose parsers, and will never be so.

If I understand correctly, C's scanf (as implemented by strtof) does not support binary exponents format for decimal floating-point expressions.

The following C code works as expected.

float f;
sscanf("7.23p", "%fp", &f);
printf("%f\n", f); // 7.230000

If you try to scan "123e" into a float, that also errors. It's not the existence of binary exponents that's the issue, it's a general problem with floats that does not occur with integers: https://play.golang.org/p/gqzbRPWPebU and https://play.golang.org/p/01gHSOypDwT

Marking this as a bug, changing the title, and setting it for go1.11. Still not sure I can find a clean fix, but it might be possible. The inconsistency should be resolved.

Copying a comment @rsc made on the wrong issue:

FWIW, at least on my Mac, sscanf doesn't care how long an integer is, even if it's too long:

#include <stdio.h>

int main() {
int d;
d = 0;
printf("%d\n", sscanf("11111111111111111e", "%de", &d));
printf("%d\n", d);
return 0;
}

prints

1
651588039

I see the same results with GCC on Linux.

I believe the reason that happens is because sscanf, for whatever reason, uses strtol for scanning int, and as strtol returns a long it does bound checks accordingly, so the overflow happens when the long returned by strtol is assigned to an int.

So, if one uses long instead of int for d, and gives a large enough value, it errs as expected:

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>

int main() {

  long d = 0;
  printf("sscanf: %d\n", sscanf("11111111111111111111111111e", "%lde", &d));
  printf("d:      %ld\n", d);
  printf("err:    %s\n", strerror(errno));

}

sscanf: 1
d:      9223372036854775807
err:    Numerical result out of range

This is all very unholy. No int with scanf.

To fix this would require three-rune lookahead, which is an unbearable burden. You could get "3e+x" and need to read all the way to the "x" to learn that you should stop scanning at the 3 for a legal float.

This is not practical given the way Scanf is meant to work with an arbitrary input feed. One rune lookahead is fine, but three runes is too hard.

Closing as unfortunate.

Fair enough, some documentation of this limitation would be good still, at least there should be a mention of how p is supported. It could save some other unfortunate soul some frustration.

It's got nothing to do with 'p' beyond 'p' being an exponent marker for floats.

The fmt package does not mention anything about the binary-exponent (p) in floating-points. Only e and E.

#24453