Hmm...
I've changed the original source of the data to not use signed ints, so I
can't re-verify the original problem at the moment. I have run your
tests and they appear to be correct here as well.
The problem with %F still stands, though, I think, as the first line
doesn't work but second does:
array_sscanf(sprintf("%-F", 4.3), "%-F");
(4) Result: ({ /* 1 element */
-6.35011e-23
})
array_sscanf(reverse(sprintf("%-F", 4.3)), "%-F");
(5) Result: ({ /* 1 element */
4.3
})
Which is definitely not correct behavior, right?
Additionally, I did run into a problem using the + modifier in sprintf():
while the resulting string is encoded as signed, it prepends a +, which
seems incorrect to me, such that it's not possible to decode without first
removing the +:
array_sscanf(sprintf("%-+4c", -65335), "%-+4c");
(16) Result: ({ /* 1 element */
-16725717
})
array_sscanf(sprintf("%-+4c", -65335)[1..], "%-+4c");
(18) Result: ({ /* 1 element */
-65335
})
On Wed, 22 Jun 2011, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-)
developers forum wrote:
1. The + and - modifiers to %c don't seem to work in combination, even though
it seems reasonable that one might want to decode a signed value in big endian
order. Separately they work fine.
(ITYM "little endian"...)
Seems working to me:
Pike v7.8 release 350 running Hilfe v3.5 (Incremental Pike Frontend)
array_sscanf("\xff\xf0","%+-2c");
(1) Result: ({ /* 1 element */
-3841
})
array_sscanf("\xff\xf0","%-+2c");
(2) Result: ({ /* 1 element */
-3841
})
