This (from the op, not from Kaz) reads as nonsense. Half the union is unused so that should be a uint32_t. Looks like a failed attempt to bypass aliasing limitations. The out of bounds read is bad, would segv if you aimed shortly before a page you don't have permission to read. Maybe the subsequent shuffling does something useful but it's dubious to be returning a single uint8_t and a boolean (upcast to an int, weirdly) per four bytes of input.
Took another look at it and can't work out the interface. Reading ascii in base 10, but 'len' claims to be the length of the string and not how many digits to read, and the behaviour is roughly return 0 on non-ascii-numeric-char.
Maybe it's quicker than the unrolled loop, though I suspect if you mark the pointer aligned 4 (which would make the reading past the end segv-safe) the compiler would produce a single load for you from the byte at a time code.