[R-SIG-Mac] Unexpected behavior from sprintf()
murdoch.duncan at gmail.com
Wed Apr 25 03:12:47 CEST 2012
On 12-04-24 5:12 PM, Simon Urbanek wrote:
> On Apr 24, 2012, at 4:24 PM, Joran Elias wrote:
>> I stumbled across this by accident from this StackOverflow question:
>> and a subsequent discussion in the StackOverflow R chat room:
>> The issue is the output from the following code:
>> It appears that when this is run in OS X in either 2.14.2 or 2.15.0, the
>> output is:
>>  "00001" "00002" "00003" "00004" "00005"
>> whereas when it is run on other platforms (I saw examples from various
>> Windows versions and one user on Ubuntu, all using 2.15.0 I believe) you
>>  " 1" " 2" " 3" " 4" " 5"
>> There was some uncertainty as to which behavior is "expected".
> The behavior of "%0s" is undefined -- this is documented both by R and POSIX (arguably more clearly in the latter), so any behavior should be expected.
>> Does anyone
>> have any insight into which behavior is "correct" and whether this is a bug
>> or not?
> It is not a bug. The formatting is done by the OS, so the results are always OS-dependent -- since %0s is undefined, the OS can choose to interpret it any way it wants.
Here's a slightly related question: If a single percent sign appears in
a string, not as the start of a conversion spec, is the behaviour
defined? For example, something taken from the R do_sprintf source in
one of the error messages:
"the '%*' constructed 'fmt2' exceeds maximum of %d"
There's certainly one decimal value to be displayed at the end, but is
the %* guaranteed to be interpreted literally? The R sprintf parser
gets confused by this one, but it's actually in the C code; is it a
legal C format string?
More information about the R-SIG-Mac