[R-SIG-Mac] Unexpected behavior from sprintf()

[Duncan Murdoch]

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:
>>
>> http://stackoverflow.com/q/10300325/324364
>>
>> and a subsequent discussion in the StackOverflow R chat room:
>>
>> http://chat.stackoverflow.com/transcript/message/3431991#3431991
>>
>> The issue is the output from the following code:
>>
>> sprintf('%05s',as.character(1:5))
>>
>> It appears that when this is run in OS X in either 2.14.2 or 2.15.0, the
>> output is:
>>
>> [1] "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
>> get:
>>
>> [1] "    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?

Duncan Murdoch