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:
- 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 })